ドメインモデルを少し理解し、設計に正しくアプローチしていることを確認するために、いくつかの助けを借りることができます。
Departmentという集約ルートがあります。Departmentオブジェクトには、「department」のビジネス概念を定義するのに役立ついくつかの子値タイプがあります。私のUIでは、ユーザーは部門オブジェクトを一覧表示、作成、編集、および削除できます。
Projectという別の集約ルートがあります。プロジェクトにはいくつかの子値タイプがありますが、各プロジェクトが部門によって「所有」されているという点で部門とも関係があります。プロジェクトは作成、編集、削除などが可能であり、そうしても部門に影響はありませんが、部門を削除すると、所有しているプロジェクトもすべて削除されます。
私のUIには、現在のユーザーがアクセスを許可されている部門に基づいたプロジェクトのリストが表示されます。複数の部門にアクセスできる場合があります。リストアイテムと詳細の両方として表示される場合、プロジェクトで部門のロゴを表示する必要があります。
私が最初に考えたのは、プロジェクトは、部門を「検索」するために使用できる単純なDepartmentIDプロパティを持つ集約ルートであるということでした。しかし今、私は実際には1つの集約ルート(Department)しか持っていないと考え始めています。
どう思いますか?
アップデート
それが議論の鍵なのか、何かを変えるのかはわかりませんが、最初のいくつかの答えを読んだ後、次のような考えが浮かびました。
部門には2つのコンテキストがあるようです。
- 変更をサポートするスタンドアロンエンティティとして。
- プロジェクトの子として、この場合は読み取り専用データが含まれ、動作はありません。
これにより、モデルに2つの「オブジェクト」(ケース#1の集約ルートとケース#2の値型)が必要だと思います。私は正しい方向に進んでいますか?