ドメイン駆動設計入門を読んだ

所謂DDD本は、概念的なことしか書いておらずどう実装すれば、よいかわからない。この本は、軽量DDDと呼ばれているような実装パターンだけを説明しているわけでも、概念だけを説明しているわけでもなく、個人的にちょうど良い塩梅で書かれている。（実装パターンよりではあるが）
その塩梅がこの本のよい評判の理由だと思う。

また、DDDを実現するための実装は、オブジェクト指向を基に書かれており、私としてはDDD本を読んだときより、オブジェクト指向の理解度が進んでいたので、より実装に興味を持って読み進めることができた。（成瀬さんはTwitterでDDDの実装はオブジェクト指向でなくても構わないと言っていた（はず））

この本では、ドメイン駆動開発を

ドメインの知識に焦点をあてた設計手法です

と定義しており、ソフトウェア開発におけるドメインは、

プログラムを適用する対象となる領域

と定義していました。

ドメインを理解して、課題解決に役立つものを抽出し、ソフトウェアに反映させるのが、ドメイン駆動開発と解説されています。

印象に残っているのは、ドメインサービスとアプリケーションサービスの違いが説明されており、この違いを説明しているものはあまり多くない気がする。

ドメインサービスは、値オブジェクトやエンティティなどのドメインオブジェクトがもつと不自然な振る舞いを書きます。たとえば、ユーザ名の文字数を制限する振る舞いは、ユーザ名の値オブジェクトに書きます。一方で、ユーザ名の重複を調べる振る舞いをUserクラスに書くと重複を自分自身に対して問い合わせることになり、不自然な振る舞いになります。そんなときに使用するのが、ドメインサービスです。すべての振る舞いをドメインサービスに書くこともでき、他のドメインオブジェクトがデータを保持するオブジェクトになってしまいます。このような状態をドメインモデル貧血症と呼ばれています。このような状態を避けるため、筆者は可能な限り、ドメインサービスを使わないことをおすすめしています。

アプリケーションサービスは、

ユースケースを実現するオブジェクトです。

と解説されています。ユーザを登録する、ユーザを編集するなどがユースケースであり、これらの処理をまとめたものが、アプリケーションサービスです。アプリケーションサービスには、ドメインの振る舞いを一切持たせないようにするべきで、ドメインオブジェクトを用いた処理を行うことが、役割です。

また、凝縮度の話は、最近どうしたら変化に強い（影響範囲を限定できるか）ということをよく考えており、LCOMは初めて聞いたので、インスタンス変数がどれくらい使われているかは意識していきたい。

LCOMとは、Lack of Cohesion in Methodsの略で、すべてのインスタンス変数は、すべてのメソッドで使われるべきという思想で計算される凝縮度の指標です。すべてのインスタンス変数がすべてのメソッドで使われている状態が凝集度が高く、各メソッドにおいて、使われているインスタンス変数が減るほど凝集度は低くなります。