![](https://cdn-ak-scissors.b.st-hatena.com/image/square/e2710a35b809049084fe3718226db49b364b1087/height=288;version=1;width=512/https%3A%2F%2Fres.cloudinary.com%2Fzenn%2Fimage%2Fupload%2Fs--0LKQPmSR--%2Fc_fit%252Cg_north_west%252Cl_text%3Anotosansjp-medium.otf_55%3ADDD%2525E3%252581%2525A8ORM%2525E3%252581%2525AEEntity%2525E3%252582%252592%2525E6%2525B7%2525B7%2525E5%252590%25258C%2525E3%252581%252597%2525E3%252581%2525AA%2525E3%252581%252584%2525E3%252581%25259F%2525E3%252582%252581%2525E3%252581%2525AE%2525E8%252580%252583%2525E3%252581%252588%2525E6%252596%2525B9%252Cw_1010%252Cx_90%252Cy_100%2Fg_south_west%252Cl_text%3Anotosansjp-medium.otf_37%3Aseihmd%252Cx_203%252Cy_121%2Fg_south_west%252Ch_90%252Cl_fetch%3AaHR0cHM6Ly9zdG9yYWdlLmdvb2dsZWFwaXMuY29tL3plbm4tdXNlci11cGxvYWQvYXZhdGFyL2Q4NTBhODRjMWYuanBlZw%3D%3D%252Cr_max%252Cw_90%252Cx_87%252Cy_95%2Fv1627283836%2Fdefault%2Fog-base-w1200-v2.png)
エントリーの編集
![loading...](https://b.st-hatena.com/bdefb8944296a0957e54cebcfefc25c4dcff9f5f/images/v4/public/common/loading@2x.gif)
エントリーの編集は全ユーザーに共通の機能です。
必ずガイドラインを一読の上ご利用ください。
記事へのコメント13件
- 注目コメント
- 新着コメント
![efcl efcl](https://cdn.profile-image.st-hatena.com/users/efcl/profile.png)
efcl
"ドメインモデリングの時点では Entity ではなかった情報が RDB を使うことで同一性を得て、 Entity として扱わざるをえなくなることがあります。以降ではそういった Entity を区別して ORMEntity と呼ぶことにします。"
![atico atico](https://cdn.profile-image.st-hatena.com/users/atico/profile.png)
atico
値オブジェクトの切り分けが難しい。人の名前は同じでも同姓同名があり得るけど、住所の場合同じ内容であれば同じものとして扱っていいので緯度経度を返すようなメソッドを備えた値オブジェクトとして切り出せる。
![turanukimaru turanukimaru](https://cdn.profile-image.st-hatena.com/users/turanukimaru/profile.png)
turanukimaru
Aggregation のルート Entity を操作しようという話。なお、Entity が 他 Entity を保持するのは普通にある。ただし配送先そのものは Entity ではない。配送先の先には必ず配送「相手」がいるはずなので Entity にしたいならこちら。
![yojik yojik](https://cdn.profile-image.st-hatena.com/users/yojik/profile.png)
yojik
配送先をUserに埋め込むのはDDD流儀での正解?なだけで、OOモデリングとして決して間違いとは言い切れず配送先Entityがあってもいいーじゃんとも思う。(その方が配送という業務の多様化に対応できる気さえする)
![kako-jun kako-jun](https://cdn.profile-image.st-hatena.com/users/kako-jun/profile.png)
kako-jun
以前ならばモデルをテーブルで永続化できればいい程度だったのに、DDDではユーザーに見せるべきでないモデルを見せていいの?まで考える必要があるのね。RailsのActiveRecordなら子テーブルのCRUDを自動生成しなかったと思う
注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています
![アプリのスクリーンショット](https://b.st-hatena.com/bdefb8944296a0957e54cebcfefc25c4dcff9f5f/images/v4/public/entry/app-screenshot.png)
いまの話題をアプリでチェック!
- バナー広告なし
- ミュート機能あり
- ダークモード搭載
関連記事
DDDとORMのEntityを混同しないための考え方
2つの ”Entity” ある種の ORM では RDB のテーブルスキーマモデルとなるクラスのことをEntityと呼んで...要を表示
2つの ”Entity” ある種の ORM では RDB のテーブルスキーマモデルとなるクラスのことをEntityと呼んでいます。例えば PHP のDoctrineや TypeScript のTypeORMなどがそうです。 そういった ORM を採用したプロジェクトで DDD に取り組むとき困るのが用語の衝突です。ORM の Entityは RDB のための定義を含むため当然 DDD の Entityとは異なるのですが、なにぶん同じ名前なので混同してしまいがちです。 本記事では両者を混同せず扱うための考え方をまとめます。 Entityの定義 まずは定義から確認します。 DDD での定義 エヴァンス本の日本語訳から引用します。 主として同一性によって定義されるオブジェクトはエンティティと呼ばれる Eric Evans. エリック・エヴァンスのドメイン駆動設計 (Japanese Edi
2020/12/17 リンク