5

ドメインモデルからのサービス(Windsor IoCコンテナのようなプロセスローカルコンポーネントの意味で)を使用する可能性を比較します。ドメインオブジェクトからサービスにアクセスするための規則

私はこれを達成するための3つの方法があります。

  1. ドメインイベントを公開し、それをモデルオブジェクト

  2. 上のメソッドを介してサービスを注入

  3. を扱うサービス層のコードを有しますモデルオブジェクトへのサービスの注入

(4。

最初は非常に表現力豊かで反復的なパターンになり、他の単純なタスクでは手続き型のドメインイベントとハンドラが作成されます。しかし、それはモデルが使用されている環境(モデルは自己定義されている)からモデルを切り離すのが最良です。

2番目の引数は、メソッドの引数を長くし、カプセル化を破るように見えます(モデルオブジェクトのアクションが他のサービスを必要とする場合は、すべての呼び出し元を変更する必要があります)。

3つ目は、現在のトランザクションでは不要な依存関係を挿入します。また、このためにNHibernateを拡張する必要があります。私は他の勧告が読んでいるので、この方法を避けるだろう。

私はこれを私たちのドキュメントに書いておきたいので、読者にいつどの方法を使うべきかを伝える必要があります。私は、行に沿って何かを考えています "ドメインアセンブリの中にドメインイベントハンドラを置く場合はメソッド注入を使用する"が、本当にポイントに当たっていません。

このルールの推奨事項はありますか?

答えて

8

AR(集約ルート)がサービスから何らかのデータを必要とする場合、そのデータは依存性(サービスではない)とみなす必要があります。基本的に、ARはサービスについて全く知りません。

実際には、コンストラクタに注入する意味がない犠牲となるメソッドがある場合は、それをメソッドの引数として渡します。私はあなたがサービスを渡すべきだとは思わないが(それは依存する)、必要なデータを直接渡す。

ARが物事を更新するサービスを必要とするようなものをARが行った場合、私は動くメッセージが動く(イベントを生成する)方法だと思います。

NHibernateまたは他の詳細については、ARはそれらについて知る必要はありません。ドメイン概念でない場合は、ARから遠ざけてください。

個人的には、ARをモデル化してサービスを必要としないようにしています。複数のARがシナリオに含まれているので、信頼できるサービスバスでドメインイベントを使用します。これは、dbトランザクションが問題にならないことを意味します。私はトランザクション内のものをAR内、より正確にはARリポジトリ内に保持します。他のすべてのものは最終的な整合性があります。

+0

非常に良い答えです(特にデータのポイントが顕著です)。私はルールを作るでしょう: "ドメインイベントを使う"。私はそれが "ドメイン概念"であるサービスを使用するためにはかなり手続き的であり、反復的であると感じていますが、それは最も問題の少ないルールです。 – sanosdole

関連する問題