DDDとORMのEntityを混同しないための考え方

２つの ”Entity” ある種の ORM では RDB のテーブルスキーマモデルとなるクラスのことをEntityと呼んでいます。例えば PHP のDoctrineや TypeScript のTypeORMなどがそうです。 そういった ORM を採用したプロジェクトで DDD に取り組むとき困るのが用語の衝突です。ORM の Entity は RDB のための定義を含むため当然 DDD の Entity とは異なるのですが、なにぶん同じ名前なので混同してしまいがちです。 本記事では両者を混同せず扱うための考え方をまとめます。 Entity の定義 まずは定義から確認します。 DDD での定義 エヴァンス本の日本語訳から引用します。 主として同一性によって定義されるオブジェクトはエンティティと呼ばれる Eric Evans. エリック・エヴァンスのドメイン駆動設計 (Japanese Edi

[yojik]

配送先をUserに埋め込むのはDDD流儀での正解?なだけで、OOモデリングとして決して間違いとは言い切れず配送先Entityがあってもいいーじゃんとも思う。(その方が配送という業務の多様化に対応できる気さえする)

[kobito19]

何でProfile型やAddress型が必要なのが前提になっているのかがわからないけど

[dorapon2000]

“個人的に検討中なのですが、集約の手法をつかい ORMEntity の CRUD が集約ルートを介してのみ行われるようにするのが重要だと考えています。”

[efcl]

"ドメインモデリングの時点では Entity ではなかった情報が RDB を使うことで同一性を得て、 Entity として扱わざるをえなくなることがあります。以降ではそういった Entity を区別して ORMEntity と呼ぶことにします。"

[atico]

値オブジェクトの切り分けが難しい。人の名前は同じでも同姓同名があり得るけど、住所の場合同じ内容であれば同じものとして扱っていいので緯度経度を返すようなメソッドを備えた値オブジェクトとして切り出せる。

[sonota88]

（DDDの話に乗っかると）profile, address のサロゲートキーはドメインの関心事ではなくDB側の都合だからリポジトリで隠蔽しましょうという話になるのかな

[syukit]

DDDにおいてもライフサイクルの観点で見たら、RDB内のデータソースはリポジトリで隠蔽されたエンティティって言えるんじゃないの？

[vuy]

ん？ドメインレイヤーがインフラに？同名であってもnamespace, packageなりで区別できるのでは？/ああAgregateがいるのか

[turanukimaru]

Aggregation のルート Entity を操作しようという話。なお、Entity が 他 Entity を保持するのは普通にある。ただし配送先そのものは Entity ではない。配送先の先には必ず配送「相手」がいるはずなので Entity にしたいならこちら。

[lalupin4]

そのために Aggregate があるんじゃなかったっけ？

[n_231]

“address テーブル” にid 持たせずにusr_id と住所枝番でキーにしとけばそういう表現になるのでは、という気がしなくもない

[kako-jun]

以前ならばモデルをテーブルで永続化できればいい程度だったのに、DDDではユーザーに見せるべきでないモデルを見せていいの？まで考える必要があるのね。RailsのActiveRecordなら子テーブルのCRUDを自動生成しなかったと思う

[a_suenami]

よかった（こなみ