「制御の反転」は「貧血領域モデル」を促進しますか？

前回のプロジェクトでIoC Containerを使用したとき、貧弱なエンティティとステートレスサービスでのビジネスロジックの大部分になりました。

「Inversion of Control」を利用する他の開発者によって書かれたプロジェクトを見てきましたが、それらは常に「Anemic」です。

「Anemic Domain Model」はアンチパターンであるため、IoCとRich Domainを使用できますか？彼らの良い例、それを行うオープンソースプロジェクトはありますか？

まず、DIとIoC は同義語ではありません。申し訳ありませんが、私はそれを指摘しなければなりません（あなたは彼らがそうだと思うようです）。

お問い合わせは...依存性注入は単なるツールです。このツールの使用方法は完全に別のものです。問題を追加する可能性のある他のツール（設計パターン）もあります。たとえば、MVCパターンを広く採用することは、Anemic Domain Modelアンチパターンを形成するための重要な要素の1つであると感じています。 、それらを強制するだけでなく、DBエンティティを何か有用なものに変換します。一方、ビジネスレイヤーは、データベースエンティティに1対1でマッピングされる単純なORMである単純なデータアクセスレイヤーになります。

確かにアプリケーションの設計方法です。必要に応じて適切なドメインモデルを作成できます。これらすべてのIoC、DI、MVCによって停止することはありません。あなたを止めることができるのはあなたのチームです。あなたはどういうわけか彼らに正しい道を使うよう説得する必要があり、多くのソフトウェア開発者は強力なアーキテクチャの背景を持っていないので難しいかもしれません。

ほとんどの（すべてではないにしても）アプリケーションは、インフラストラクチャとドメインの懸念が混在しています。特定のレベルの複雑さに達すると、ドメインがインフラストラクチャから分離されている場合、管理が容易になり、推論が容易になり、独立して進化できるようになります。

もちろん、ドメインモデルはシステムの残りの部分と通信する必要があり、通常、インフラストラクチャの問題（データベースアクセスなど）が注入されたステートレスサービス（ドメインの一部）と通信します。IoCコンテナーを使用しても、この依存関係は削除されず、その構成が別の領域に移動されます。これも、推論と保守が容易になります。

エンティティは状態を保存しており、ビジネスルールを担当する必要があります。サービスがすべての不変条件およびその他のビジネスルールを実施している場合、ロジックが間違った場所にある可能性があります。

ロジックを適切な場所に配置したにもかかわらず、インフラストラクチャの単なるラッパーであるサービスや、単なるプロパティバッグであるエンティティに終わった場合、ドメインは正当化するほど複雑ではない可能性が非常に高い独自のモデルのオーバーヘッド。DDDについてお読みいただく内容には、複雑なドメインのみを対象とした免責事項が記載されていますが、これはあまりにも忘れられがちです。

ソースに移動します。貧血領域モデルに関するファウラーの作品から始めてください。彼は、優れた実践の例としてエリック・エヴァンのドメイン駆動設計を参照しています。そのためのソースコードはこちらです。ダウンロードしてください。

Inversion of Control（@Autowiredを検索）を使用し、サービスクラス（BookingService）と「ビジネスプロセス」クラス（ItineraryUpdaterなど）を持っていることを確認します。

ファウラーの元の記事は、あなたが探している例への道を開きます。

IoCとリッチドメインを使用できますか？彼らの良い例、それを行うオープンソースプロジェクトはありますか？

IoCの代わりにDIを意味すると仮定し、あなたが取り組んだプロジェクトはSpringのようなDIコンテナを使用しています。IoCには、DIとロケーターパターンという2つの主なフレーバーがあります。Locatorパターンが問題になる理由がわからないので、DIに注目しましょう。

私はそれが可能だとは思わない、または少なくとも非常に非現実的だろう。DIコンテナーの主な特徴は、オブジェクトを他のオブジェクト（「管理オブジェクト」）に注入するときにオブジェクトの作成を制御することです。プロジェクトの実行時に生存している管理対象オブジェクトのセットは、プロジェクトに存在するドメインアイテムから独立していますが、オブジェクトの配線方法とそれらに割り当てられるスコープ（シングルトン、プロトタイプ）に依存します。

これが、DIコンテナにドメインオブジェクトを管理させたくない理由です。ただし、オブジェクトを（新規で）手動で作成する場合、他のオブジェクトをドメインオブジェクトに挿入することはできません。（手動の配線を回避する潜在的な回避策を残します。）実装を他の実装に置き換えるためにこれらの注入が必要なため、DIを使用してリッチドメインオブジェクトの機能を置き換えることはできません。したがって、ドメインオブジェクトに機能を配置したくない、またはDIの機能を失うことになります。

オブジェクトを管理しない架空のDIコンテナーがどのように機能するかはわかりませんが、既存の実装ではそれが許可されていません。したがって、DIがオブジェクトの管理に依存していると主張するのは公平です。したがって、潜在的なリッチドメインオブジェクトを1つの貧弱なクラスと1つまたは複数のトランザクションスクリプトクラスに分割するように常に誘惑されます。