8

あるリポジトリが別のリポジトリにアクセスできることは一般的に許容されますか?特にこの場合、追加するエンティティを決定するために別の集約ルートを使用する1つの集約ルートがあります。これは、アイテム/アイテムタイプの関係に沿ったものです。アイテムタイプが集約ルートである理由は、単一のアイテムの範囲外の管理ツール内で個別に保守できるためです。

重要な場合は、リポジトリファクトリの実装を介してリポジトリインスタンスを作成するだけなので、具体的なクラス名で直接作成することはありません。アグリゲートがリポジトリを認識することはありません。

編集-詳細情報:

具体的な実装は、画像をドキュメントに添付できることです。ドキュメント上の画像を管理できるだけでなく、さまざまな種類の画像があります(たとえば、拡張機能ではなく、実装方法として定義されている種類)。ドキュメントアグリゲートは、これらのイメージを使用するシステム内の他の数種類のオブジェクトの1つであり、すべてが同じタイプを使用するわけではありません。ドメインサービスにルールを添付しますが、これはより具体的にはドキュメント集約の構築を対象としています。アグリゲートを構築するとき、特定のタイプの5つのイメージと、他の2つのタイプのそれぞれ1つがあります。これらは集約内の個別のリストに格納されるため、個別にプルします。検証は問題ではありませんが、ドキュメントを組み立てるときに評価される画像の種類を制限します。

4

2 に答える 2

6

それはあなたが何をしようとしているのかに要約されると思います。それが一種の検証ステップ (たとえば、有効期限が切れたアイテム タイプを持つすべてのアイテムを削除する) である場合は、それがサービス レイヤーまたは仕様に属していると主張できます。使用する言語 (つまり、「追加するエンティティを決定する」) からは、後者を示唆しているように見えますが、詳細がないと言いにくいです。

特にアイテムとそのタイプは集約ルートと見なすことができ、それは実装の詳細にすぎないため、特定の観点から、できない本当の理由はないと思います(私は決して最も純粋なDDDではありません)。防止する管理コンソールを提供する必要があること。

別の観点からは、2 つの異なるコンテキストが機能していることを示唆する可能性のある集約ルート間にぼやけがあることを示唆しているようです。たとえば、管理ツールはメイン アプリケーションに対して別の境界付けられたコンテキストを形成するため、アイテム タイプが集約ルートであるというケースは実際には当てはまらないと主張する人がいるかもしれません。たとえば、管理ツールはアイテム タイプのみに関係している (アイテムにはまったく関係がない) 場合がありますが、メイン アプリケーションはアイテム タイプをエンティティよりも値オブジェクトのように見なす場合があります。

アップデート

ドキュメントのアセンブルについて言及したように、これは有効なエンティティを正しくアセンブルできるファクトリ クラスの責任のようです (ファクトリはイメージ タイプ リポジトリを使用できます)。リポジトリは (私の目には) エンティティを構成するためのロジックではなく、クエリと追加操作を公開する必要があります (永続化からの再水和を除く)。

于 2009-08-26T19:20:38.590 に答える