web-dev-qa-db-ja.com

「コンポジションルート」DIはドメイン駆動設計にどのように適用されますか？

DDDでアグリゲートを作成するために「コンポジションルート」（CR）を適用することについて混乱しています。 Seemann（2012）は、CRを「（できれば）一意の場所...モジュールが構成される場所」と定義しています。 CR内のアプリケーションのエントリポイントの近くにオブジェクトグラフを作成すると主張し、「小さなサブシステムを作成するために一度に少しずつクラスを作成する」という誘惑に警告します。

DDDの集計は、このようなサブシステム（エンティティと値オブジェクトを含む（サブ）グラフ）のように見えます。 Evans（2004）とその他のDDDテキスト（Vernon 2013、Ghosh 2017）は、ドメインレイヤーにあるファクトリー内、アグリゲートの近く（アグリゲートのファクトリメソッドなど）またはスタンドアロンサービスとしてアグリゲートを構築することを推奨しています。これはCRのアプローチと矛盾するようです。

問題は、CRとFactoryのアプローチをDDDで組み合わせる必要があるかどうか、またどのようにすべきかです。例えば、

  • CRは、アプリのエントリではなくドメインレイヤー内に配置されます。おそらく、工場はこの単一の場所にプールされています
    または
  • CRの利点（たとえば、「サブシステムをインターセプトして動作を変更する機能」; Seemann）は、DDDとは無関係です。
  • CR DIは、アグリゲートの作成には適用されませんが、より高い粒度レベル（サービスの注入など）で機能します。次に、CRメソッドはファクトリを使用して集計を作成し、オブジェクトグラフに配置します。

参考資料
M。 Seemann、2012、「。NETでの依存性注入」
Eエヴァンス、2004年、「ドメイン駆動設計」
V。バーノン、2013、「ドメイン駆動設計の実装」
D。 Ghosh、2017年、「機能的で反応的なドメインモデリング」

designobject-orienteddomain-driven-designdependency-injection
2
esc_space

これは、与えられた優れた回答とコメントに基づいて、私が問題に取り組む方法です。

構成ルートと集約ルートには類似点があります。前者はアプリケーショングラフ全体を構成し、後者には集約のローカルオブジェクトサブグラフ（@RobertHarvey）が含まれます。したがって、コンポジションルートを介したDIを使用して、プログラムレイヤーとレイヤー内のモジュールを構成し、必要に応じてインターフェイス実装を交換できます（@VoiceOfUnreason）。

Aggregate Rootの「近く」にあるファクトリをより細かく使用して、特定のAggregateのインスタンスを構築できます。したがって、たとえば、値オブジェクトを作成して集計を生成する方法や、特定のルールでそれを検証する方法などの知識はローカルに保たれます。また、整形式のドメイン概念を表す集合体の場合、内部メンバーの柔軟な実装は必要ない場合があります。それでも、コンポジションルートDIを使用して、集約ファクトリをクライアントに注入することができます（@Euphoric）。

要約すると、私は階層的アプローチを試み、Composition Rootモジュールからのより高いレベルのDIをより低いレベルの集約ファクトリーと混合します。

0
esc_space