根幹のEntityの設計がダメだとapplication全体が複雑化してしまう

applicationの根幹を担うEntityの設計の仕方を手順化したい

手順化とまでは言わずとも、設計時に着眼すべきポイントのようなものはあると思う

良い感じの資料・方針

Entityの関連付け

Entity間の依存はどうするか

あるEntityが持つpropertyの1つに他のEntityが含まれる場合

PBFをやっている時に、どういうimportになるのか

Entityに限らず

そのEntityが、productの中でどういう状態を持つか？などを考える

その後、

そのEntityにAccidental Complexityが含まれていないかを確認する

Accticentalの中の分離を行う

付随的だが役に立つものとそうでないものにわける

「役に立つもの」はパフォーマンス的にキャッシュしとくと嬉しい、ぐらいのことを指している

Entityには

Essential Complexity(下図の緑)

Essential Logic(下図の青)

必須なAccidental Complexityを計算するロジック

派生データをもとに計算することで、状態を持たない

Persistent Accidental Complexity(下図の黄色)

Accidental Complexityだが、諸事情により永続すべきと判断したもの

依存関係

外部境界はControllerなどアプリケーションの表層に近いもの

/mrsekut-book-477419087X/103とかは、そういう流れになっている

「年齢」という概念が、業務の関心であるなら、「年齢」というEntityを作る

そこに、年齢に関するロジックを凝集させる

domain modelingという感じがする

/mrsekut-book-4798121967/262 (それほど明白でない概念をモデル化する方法)~

Entity内のmethodとして制約を関数で定義していく時の話

1つ1つの制約を、小さい1つの関数に分ける

1つ1つの制約を表す関数名は長くなる

↑これらの長い関数はprivateにしておき、

短い名前の関数をpublicにする

Strategyパターンはそういう感じか