DDD/DI（Unity）/ .NET/Composition Root - ドメインサービス

Question

標準のOrder/OrderLineItem設定があります。

昼間に払い戻された払い戻しの数は、その日中も維持されます。払い戻しは、注文IDと1つ以上のLineItemIdで構成されます。クレジットカード、ギフトカード、特典カードなどに適切な期日の払い戻しが終了したら、これらを（Windowsサービスで）統合する必要があります。

私はMark Seemann's bookを読んでおり、Composition Rootを使用してオブジェクトグラフを掘り下げることの利点が分かります。

統合プロセス自体は、私が最も多くの構成を行う必要がある場所です。

私は理解していないことは、この統合ロジックがどこに終わるべきか正確には分かりますか？統合論理がどこに終わっても、構図ルートにUnityのようなものしか使用していないと考えても構いません。

さらに詳しい情報を提供したり、必要に応じて明確にしてください。

Answer 1

統合プロセス自体は、最も多くの構成を行う必要がある場所です。

したがって、システムにデータを作成するプロセスでは、ほとんどのドメインオブジェクトが作成されます。

これは意味があり、ほとんどのアプリケーションに対応しています。

この統合ロジックが終わるはずのことはわかりません。

統合ロジックは、おそらく一つ以上のrepositoryコンポーネントと1つまたは複数のunit of workコンポーネントを利用することを、1つ以上のサービス・コンポーネントによって提供されます。そのサービスはコンポジションルートで構成されますが、最終的に作成するリポジトリ/作業単位も同様です。

データ自体は完全に動的です。データのレイアウトを静的に知るようにアプリケーションを構造化することはできません。そのため、コンポジションルートでデータのレイアウトを作成することはできません。あなたも試してはいけません。代わりに、コードでORMを使用して、ドメインデータオブジェクト間のリレーショナルスキーマを定義またはマップできます。

次に、リポジトリ/作業単位を使用して、ストレージからデータを取得できます。あなたはまた、newを使って新しいデータを作成するためにUI /サービスを使用します。純粋なデータであり、依存関係がないことが保証されているドメインオブジェクトには恥ずべきことではありません。新しいデータまたは変更されたデータをリポジトリ/作業単位に保存します。

このようにすると、コンポジションルートから注入されたファクトリパターンを使用して、それらのオブジェクトを作成できます。しかし、低レベルのドメインオブジェクトをDTOsに構成していれば、これは何かがあればそれほど購入しません。

すべてを提供するためにUnityを使用する必要はなく、システムのすべてのオブジェクトをコンポジションルートに絶対作成する必要はありません。しかし、システムの静的な部分、または静的に構成可能な動的なシステムを構成ルートに作成するようにしてください。これはUnityのようなDIコンテナに非常によく似ています。

Answer 2

払い戻しの項目が単にサービスに依存しないデータコンテナまたはエンティティの場合、単にnewを使用してインスタンスを作成することができます。

依存関係があり、IoCコンテナによって作成されなければならない場合は、ファクトリインターフェイスを使用するよりも起動時に実行できません。このファクトリインターフェイスには、作成されたインスタンスに渡す必要なすべてのパラメータを取得するCreateRefundメソッドが含まれています。このインタフェースは、コンシューマのネームスペース/アセンブリで定義されています。

このインターフェイスの実装は、IoCコンテナによって異なります。コンテナによっては、コンフィグレーションで指定するだけで、インターフェイスがコンテナによって自動的に実装される機能があります。 Unityのようなものは、手動で実装する必要があります。この実装は、コンテナ設定の一環としてComposition Rootに存在します。実装がコンテナのインスタンスを取得し、それを使用して要求されたRefundインスタンスを作成します。

この方法では、コンテナにアクセスする唯一の場所はComposition Rootです。