Photo by
yomogi86
読書ログ：『ドメイン駆動設計入門-３、４章』
このnoteは「ドメイン駆動設計入門」の読書記録です。
３章-ライフサイクルのあるオブジェクト「エンティティ」と４章-不自然さを解決する「ドメインサービス」を読みました📚
ドメインの概念を表現するオブジェクト
ドメインの概念を表現するオブジェクトには値オブジェクトとエンティティがある。ライフサイクルが存在すればエンティティ、そうでなければ値オブジェクト。例えばユーザーのように作成後にユーザー名が変更されたり月日が経ち削除されたりと変化があるものはエンティティで表現する。エンティティは同一性を表す識別子（id）で区別できる。
ドメインオブジェクトを定義するメリット
コードのドキュメント性が高まる。
開発者はコードを手掛かりにそこに存在するルールを確認できる。
ドメインにおける変更をコードに伝えやすくする。
ドメインオブジェクトにふるまいやルールを記述することで修正が容易くなる。
ドメインサービス
値オブジェクトやエンティティに記述すると不自然になってしまうふるまいはドメインサービスに記述する。例えばユーザー名を登録する際に重複をチェックする処理があった場合、Userクラスにその処理を持つと自身に対する重複の問い合わせを行い不自然さを感じる。
ドメインサービス（UserServiceクラスなど）にその処理を持つことで不自然さは解消される。
ドメインモデル貧血症
なんでもかんでもドメインサービスに持つとドメインオブジェクト側にはゲッターとセッターだけが残り、これを見ただけではどのようなふるまいやルールが存在するのか読み取ることが難しい。
語るべきことを何も語っていないドメインオブジェクトの状態を「ドメインモデル貧血症」と呼ぶ。
ドメインサービス濫用 -> データとふるまいの断絶 -> ロジックの点在 -> ソフトウェアの変化の阻害や停滞
とならないように注意。