Entityの設計
根幹のEntityの設計がダメだとapplication全体が複雑化してしまう
applicationの根幹を担うEntityの設計の仕方を手順化したい
手順化とまでは言わずとも、設計時に着眼すべきポイントのようなものはあると思う
良い感じの資料・方針
immutable data model
『Domain Modeling Made Functional』
『Out of the Tar Pit』
#WIP
Entityに対してinsideでIdentifierを定義する
Entityの関連付け
Aggregate
Entityが状態を持つことの問題点
Entityから状態を追い出す
Entity間の依存はどうするか
あるEntityが持つpropertyの1つに他のEntityが含まれる場合
PBFをやっている時に、どういうimportになるのか
Entityに限らず
個々の文脈で完全なデータ型を定義する
仕様の意図をデータ構造に落とし込む
Entityの単一性・同一性・カテゴリ
そのEntityが、productの中でどういう状態を持つか?などを考える
個々の文脈で完全なデータ型を定義する#61d4459719827000006a68bb
その後、
そのEntityにAccidental Complexityが含まれていないかを確認する
Accticentalの中の分離を行う
付随的だが役に立つものとそうでないものにわける
「役に立つもの」はパフォーマンス的にキャッシュしとくと嬉しい、ぐらいのことを指している
Entityには
Essential Complexity(下図の緑)
Essential Logic(下図の青)
必須なAccidental Complexityを計算するロジック
派生データをもとに計算することで、状態を持たない
Persistent Accidental Complexity(下図の黄色)
Accidental Complexityだが、諸事情により永続すべきと判断したもの
https://gyazo.com/7a163a05cec11e4489e115fc0b27d97e https://tech.uzabase.com/entry/2021/05/20/141950
依存関係
https://gyazo.com/2a3ef4fa5fe80010aedc7aade0e4faa4 https://tech.uzabase.com/entry/2021/05/20/141950
外部境界はControllerなどアプリケーションの表層に近いもの
そこに業務の関心があるなら新しくEntityを作る
/mrsekut-book-477419087X/103とかは、そういう流れになっている
「年齢」という概念が、業務の関心であるなら、「年齢」というEntityを作る
そこに、年齢に関するロジックを凝集させる
domain modelingという感じがする
Entityを小さく作る
/mrsekut-book-4798121967/262 (それほど明白でない概念をモデル化する方法)~
Entity内のmethodとして制約を関数で定義していく時の話
1つ1つの制約を、小さい1つの関数に分ける
1つ1つの制約を表す関数名は長くなる
↑これらの長い関数はprivateにしておき、
短い名前の関数をpublicにする
Strategyパターンはそういう感じかmrsekut.icon
DDDのトリレンマ
immutable data model