WorkItemドメインモデルの一部として、オブジェクトがあるとしましょう。オブジェクトには、次のWorkItemようなルックアップ値との関係がいくつかあります。
WorkItemType：
Priority：
Statusそして、、、などのように、おそらくもっとあるかもしれませんSeverity...
DDDは、アグリゲートルート内に何かが存在する場合、アグリゲートルートの外部でアクセスを試みるべきではないと述べています。したがって、Taskなどの新しいWorkItemTypesやCriticalなどの新しいPrioritiesを追加できるようにする場合、これらのルックアップ値は独自のリポジトリを持つ集約ルートである必要がありますか？これは、特にキーと値のペアにすぎない場合は、少しやり過ぎのようです。ユーザーがこれらの値を変更し、集約ルートカプセル化ルールに準拠できるようにするにはどうすればよいですか？
ブルーブックで説明されているリポジトリ パターンは、その使用が集約に限定されていることを強調していますが、例外の余地が残されています。本を引用するには：
ほとんどのクエリはオブジェクトまたはオブジェクトのコレクションを返しますが、オブジェクト数や、モデルが集計することを意図した数値属性の合計など、一部の種類の集計計算を返すことも概念に適合します。(152ページ)
これは、集計ではない要約情報を返すためにリポジトリを使用できることを示しています。この考え方は、ユース ケースで必要とされるように、リポジトリを使用して値オブジェクトを検索することに拡張されます。
考慮すべきもう 1 つのことは、基本的にクエリのみのタイプのリポジトリを可能にする読み取りモデル パターンです。これにより、動作が豊富なドメイン モデルをクエリの懸念から効果的に切り離すことができます。
ランドン、唯一の方法は、これらの値のペアを集約ルートにすることだと思います。やり過ぎに見えるかもしれませんが、それは物事を小さなコンポーネントに分割するDDDです。
リポジトリを使用することが正しい方法であると私が考える理由は次のとおりです。
DDD は一連のガイドラインであり、確固たる真実ではないことを忘れないでください。これはやり過ぎだと思われる場合は、ペアを値オブジェクトとして返すルックアップを作成することをお勧めします。アプリケーションに値のペアを追加する機能がなく、データベースを介して追加する機能がない場合、これは特にうまくいく可能性があります。
補足として、良い質問です！このような状況についてはかなりの数のブログ投稿があります... しかし、すべてがこれを行う最善の方法について同意しているわけではありません。
DDD を使用してすべてをモデル化する必要はありません。参照データの管理が複雑であるため、おそらく集約ルートを作成することは正当化されません。一般的な解決策は、CRUD を使用して参照データを管理し、ドメイン サービスを使用してドメインからそのデータとやり取りすることです。
これらのルックアップには ID がありますか? そうでない場合は、それらを値オブジェクトにすることを検討できます...