集約の実装について考えてみた

はじめに DDD の集約の実装について考えたことをまとめます。 題材 料理のレシピ作成を題材としてまとめていきたいと思います。 概要 概要は以下の通りです。 レシピには材料と作り方がある。 材料には食材や調味料などの名前と分量が必要である。 材料はメインとなる材料や合わせダレなどのカテゴリごとにグルーピングできるとよい。 作り方は具体的な手順を示すものである。 ドメインモデル 上記をドメインモデルで表現するとこのようなイメージです。 各種値の範囲はドメインとして決まっているわけではないですが、システム化する上で決めなければならないことだと思いますので、ドメインエキスパートとすり合わせながら運用に支障をきたさない範囲で決定すると良いのかなと思います。 今回は決定した値の範囲をドメインモデルに補足する形で記載しています。 ユースケース システムに対するユースケースは以下の通りとし、末端のユース

[chibahiro]

“コメントいただいた結果、やはり強い整合性を確保したいのであれば同じ集約にするのが良いという結論になりました。 同じ集約にした場合の実装例は下記 v4 パッケージにあります”

[j5ik2o]

材料リポジトリは材料テーブルだけをI/Oするはずが、外部集約の材料カテゴリのテーブルも更新するのですか？ 集約の境界が曖昧になってません？？

[turanukimaru]

やりたいことは解るが集約を考えてから適当にドメインをでっち上げてはいけない。それはドメインでないのでドメインモデルではない。ドメインがドメインであるには理由があり業務をドメインと呼んで満足しては駄目だ

[yojik]

(いきなり集約ルート考えると概念がうまくモデリングできない問題は置いておいて)材料カテゴリみたいなオブジェクトを種別ごとに分類するのにUMLには限定子という記法があるのだけど、現代ではすべて失伝している。。