ddd-entity

1 行でまとめると

エンティティとは、何を含むかではなく、何者であるかによって識別されるドメインオブジェクトです。属性が変化しても、時間が経過しても、そのアイデンティティは安定しています。

このスキルを使用する場面

• 時間の経過に伴って追跡する対象をモデル化する場合：Customer、Order、Account、Shipment、Subscription。
• 属性が同一の 2 つのインスタンスでも、別々のものとして扱う場合（「John Smith という名前の顧客が 2 人いても、同じ顧客ではない」）。
• 概念にライフサイクルがあり、作成、変更、アーカイブ、削除を経ても、同じ概念上のインスタンスが存続する場合。

このスキルを使用しない場面

• 概念がアイデンティティを持たず、属性だけですべて表現できる → ddd-value-object を使用してください。
• 「アイデンティティ」がドメイン上の意味を持たないデータベースの自動採番 ID にすぎない → その概念は実際には値オブジェクトであり、永続化層が保存の都合で識別しているだけかもしれません。
• 概念が単一の集約内にしか存在せず、外部から参照されることもない → エンティティである可能性はありますが、そもそも別個にモデル化する必要があるのか再検討してください。

中核となる内容

アイデンティティが、他と区別するための特徴です。エンティティのアイデンティティは（UUID、顧客番号のような業務識別子、自然キーなどとして）割り当てられ、安定しています。属性が変わっても変化しません。同一性はアイデンティティによって判断します。ほかのフィールドがすべて異なっていても、識別子が一致する場合に限り、2 つのエンティティは等しいとみなされます。

エンティティにはライフサイクルがあります。エンティティは（多くの場合、ファクトリーを通じて）作成され、不変条件を維持するメソッドを通じて変更され、アーカイブや削除が行われることもあります。ライフサイクルを通じて、アイデンティティは変わりません。

エンティティが公開するのは、単なるデータではなく振る舞いです。Customer エンティティには、changeAddress、closeAccount、deactivate のようなメソッドがあるかもしれません。こうしたメソッドはそれぞれ、エンティティの不変条件を守る役割を担います。顧客の状態に矛盾が生じることはありません。

判断のヒント

• 履歴を追跡する必要がある場合や、後から「同じもの」を参照する必要がある場合は、エンティティにします。
• 属性が同一であれば、あるインスタンスを別のインスタンスに置き換えても問題ない場合は、値オブジェクトにします。
• エンティティの候補に getter／setter 以外の振る舞いがない場合は、再検討してください。エンティティが貧血状態なら（振る舞いを追加する）、または分類が誤っているなら（実際には値オブジェクトかもしれません）、見直しが必要です。
• アイデンティティは属性から導出するのではなく、割り当てます。フィールドからアイデンティティを導出していることに気づいたら、値オブジェクトをモデル化している可能性が高いです。

アンチパターン

• 固有のアイデンティティを持たないものまで含め、あらゆるドメインオブジェクトをエンティティとしてモデル化すること（「エンティティの乱立」）。
• 振る舞いのないエンティティ。getter だけを持つフィールドの集まりにすぎない「貧血エンティティ」です。ddd-anti-patterns を参照してください。
• アイデンティティによる同一性判定を属性による同一性判定に置き換えること（言語アダプターの落とし穴。Kotlin の data class はデフォルトでこの動作をします）。
• データベースの行の自動採番 ID を、ドメインのアイデンティティとして扱うこと。

関連項目

• ddd-value-object — 反対のケースである、アイデンティティを持たない概念。
• ddd-aggregate — エンティティはしばしば集約ルートとして機能します。
• ddd-factory — 複雑な生成処理を伴うエンティティの作成。
• ddd-repository — アイデンティティによるエンティティの読み込みと保存。
• ddd-anti-patterns — 貧血エンティティ、識別子におけるプリミティブ型への執着。

参考文献

• Evans、『Domain-Driven Design』（2003 年）、第 5 章（A Model Expressed in Software）。