ドメインイベントを使用するか、アプリケーションレイヤーにすべてを調整させるかの選択方法

ドメイン駆動設計への最初のステップを設定し、ブルーブックとすべてを購入しました。特定のソリューションを実装するための3つの方法を見ています。記録のために：私はCQRSまたはイベントソーシングを使用していません。

ユーザーリクエストがアプリケーションサービスレイヤーに入ってきたとします。その要求のビジネスロジックは（何らかの理由で）エンティティ上のメソッドとドメインサービス上のメソッドに分けられます。これらのメソッドを呼び出すにはどうすればよいですか？

これまでに収集したオプションは次のとおりです。

• アプリケーションサービスが両方のメソッドを呼び出すようにします
• メソッドインジェクション/ダブルディスパッチを使用して、ドメインサービスをエンティティにインジェクトし、エンティティに実行させてからドメインサービスのメソッドを呼び出します（または逆に、ドメインサービスがエンティティのメソッドを呼び出すようにします）
• エンティティメソッドでドメインイベントを発生させ、そのハンドラーがドメインサービスを呼び出します。（私が話しているドメインイベントの種類は、http：//www.udidahan.com/2009/06/14/domain-events-salvation/です）

これらはすべて実行可能だと思いますが、どちらかを選択することはできません。私はこれについて長い間考えていましたが、3つのセマンティックの違いがもはや見られなくなるまでになりました。何を使うべきかのガイドラインを知っていますか？

アプリケーションサービスが両方のメソッドを呼び出すようにします

通常、アプリケーションサービスはこのための優れた出発点ですが、常にエンティティに可能な限り近い動作をシフトするようにしてください。アプリケーションサービスはオーケストレーションの役割を果たし、ドメインの動作を実行するためのステージを設定し、必要なすべての依存関係を提供します。ただし、可能であれば、動作をドメインモデルに委任する必要があります。

メソッドインジェクション/ダブルディスパッチを使用して、ドメインサービスをエンティティにインジェクトし、エンティティに実行させてからドメインサービスのメソッドを呼び出します（または逆に、ドメインサービスがエンティティのメソッドを呼び出すようにします）

これは、より多くの動作がエンティティまたはドメインサービスに委任されるため、より優れたアプローチです。これを実装する最も分離された方法は、エンティティにサービスへの依存関係を表現させることです。これは、動作を提供するメソッドのパラメータとしてです。

エンティティメソッドでドメインイベントを発生させ、そのハンドラーがドメインサービスを呼び出します。

ドメインイベントパターンは、UdiおよびEvans自身によって説明されているように、非常に用途が広く、さまざまなシナリオに適用できます。ただし、それに伴ういくつかの合併症があります。まず、ドメインイベントパブリッシャー内で適切なスコープを持っていることを確認する必要があります。ほとんどの場合、ドメインイベントハンドラーには依存関係があり、IoCコンテナーを使用している場合は、適切なインスタンスが挿入されていることを確認する必要があります。たとえば、Webアプリケーションでは、[ThreadStatic]属性はスコーピングに対して問題があります。別の複雑さは、転写境界の複雑さです。エンティティがドメインイベントを発生させ、その後のデータベースへのコミットが失敗した場合、すべてのドメインイベントハンドラーがロールバックする方法を必要とするため、トランザクションを考慮する必要があります。そうしないと、無効なイベントが発生します。ただし、これらのベースをカバーしている場合、ドメインイベントは、エンティティ自体にドメインロジックをカプセル化するための優れたパターンです。

アプローチ2とアプローチ3の違いは、ユースケースによって異なります。ドメインイベントは、過去時制のイベントに応答して追加の動作を呼び出す場合に適用されます。ドメインイベントハンドラーはエンティティの動作に影響を与えないため、これは重要な制約です。一方、アプローチ2では、注入されたサービスが特定の動作の依存関係として宣言されているため、動作に影響を与える可能性があります。