IoCコンテナとドメイン駆動設計

Question

IoCコンテナをドメイン駆動設計で使用するためのガイダンスを探しています。エヴァンの本は残念ながら問題に触れていません。私がインターネットで見つけることができる唯一の実質的なガイドラインはhereです。

Malovicのポイントの多くは常識ですが、私はそのうちのいくつかについて懸念しています。彼は、IoCコンテナはサービスのみを解決するために予約する必要があり、IoCコンテナを使用してドメインの依存関係を解決することは悪い考えだと提案しています。しかし、彼はどのような例でもこの主張を支持していない。彼はそれを事実として単純に述べている。

その後、IoCコンテナと工場を混在させることは意味をなさないと言います。これは彼の最初の点と矛盾しているようです。実際、ドメインの依存関係をIoCコンテナで解決してはならない場合、どのように解決する必要がありますか？エヴァンの本は明らかに論理的な選択肢として工場に指摘している。

あなたはこの件に関してあなたが持っているすべてのご意見をお待ちしております。私はDDDとIoCの両方については初心者です。私はIoCとDDDがどのように連携できるかを把握するのに苦労しています。

Answer 1

私の意見では、彼はドメインモデルでIoCコンテナを使用しないことについて正しいです。その練習は私自身も同様です。基本的なアイデアは、サービスにはインフラストラクチャーの依存関係が含まれている可能性があるため、それらを模擬することが賢明です。ドメインエンティティはそれらを持っていないので、それらをモックすることは重要ではありません（まだインターフェイスへのコーディングは良い方法です）。

ドメインエンティティのファクトリはIoCコンテナに置くべきではありませんが、サービスの工場はすべきです。基本的には、サービス内のエンティティファクトリを参照することができます。それは非常にタイトなカップリングではありません。 IoCの約

良い読書がBilly McCafferty's blog post "Dependency Injection 101"

Answer 2

で見つけることができIOC容器は、単位テスト可能なコードを設計する際に貴重であり、DDDに対して直交しています。あなたが望むのであれば、工場やビルダーパターンの独自の実装を作成することができます。

絶対に。特定の要件を満たすのに十分強力なIOCコンテナを使用してください。もはや、それほどではありません。

Answer 3

DDDと依存性注入（パターン）を使用しますが、依存性注入フレームワークは使用しません。

一般的な依存性注入フレームワークの1つの問題は、設定をXMLファイルに分割する方法です。 XMLは素晴らしいマークアップ言語です。どのように構成言語になった、私は理解することはありません。問題は、もちろん、すべてが正しく配線されているかどうかを知る前に、アプリケーションを実行しなければならないということです。どこのコードが使用されているかを知ることも難しいです。インターフェイスを使用している場合、インプリメンテーションへの唯一の参照はXMLファイルになります。これは見つけるのが難しくなります。そして最後に型の安全性とジェネリックスを失います。 （私はかつて我々はXMLを使用していませんでしたコンパイラによってキャッチされていたであろう生産の恐ろしいバグを見ました。）

私はその依存性注入が悪いつもりはないことを指摘しなければなりません。それは良いオブジェクトデザインの基本的なパターンです。しかし、工場で配線を行うことには何も間違いありません。私たちは、XMLファイルのうち、工場の中に「コード」を大量に削除した私の最後の二つのプロジェクトで

。ファクトリはコンテナ管理サービス（JDBC接続、JMS接続など）と結びついています。ファクトリはXMLよりもあまり冗長ではないため、アプリケーションははるかに理解しやすくなりました。そして、Javaプログラマとして、代わりにXMLをいじるの、コントロール・スペースを使用してプログラムを一緒に配線する方がはるかに簡単です - そして、あなたのIDEを使用すると、何かが壊れていたときにハイライト表示されます。

統合テストでは、工場でのようにオブジェクトを作成するだけです。

つまり、あなたが解決しなければならないのドメインの依存関係はどのような

dbConnection = DatabaseConnectionFactory.connection();  
serviceUnderTest = new PaymentProcessor(new CustomerRepository(connection));