1

ドメイン イベントを使用することは、DDD アプリケーションの実践として広く推奨されていますが、私には扱いにくいシナリオがあります。

私は最近、新しいユーザーが作成されたときに、そのユーザーが 3 つの別々のサブシステムでも作成されることをビジネス ロジックが要求するアプリケーションに取り組んでいました。したがって、基本的にトランザクション スクリプト アプローチを使用すると、次のようになります。

public void CreateUser()
{
    CreateUserInSystemA();
    CreateUserInSystemB();
    CreateUserInSystemC();
}

私が検討していたアプローチはドメイン イベントを使用するものだったので、エントリ ポイントは次のようになりました。

public void CreateUser()
{
    CreateUserInSystemA();
}

次にCreateUserInSystemA、ユーザーが作成されたときにドメイン イベントを発生させます。次に、そのイベントのハンドラーがシステム B でユーザーを作成し、別のドメイン イベントを発生させ、システム C でユーザーを作成する別のハンドラーが実行されます。これはすべて、DI コンテナーの登録中に設定されたため、ほとんどハードワイヤードでした。

質問は次のとおりです。

1) このアプローチはドメイン ロジックを効果的に隠しませんか? CreateUser メソッドを見て、実際に何をしているのかを確認するのは簡単ではありません。

2) (私たちの場合のように) システム A と B でユーザーを作成するだけでよい新しいワークフローができた場合はどうCreateUserInSystemCなるでしょうか。既存のCreateUserInSystemB実装を使用した場合、ドメイン イベントが発生し、ハードワイヤードCreateUserInSystemCは関係なく実行されます。

このシナリオを適切な DDD の方法で処理するための最良のアプローチは何ですか? アプリケーション サービス レイヤーを使用し、両方のワークフローに 2 つの個別のメソッドを公開するだけで、フローはドメイン イベントに基づかないようにする必要がありますか?

4

1 に答える 1

1

私にとって、ドメインはそれ自体がサブシステムです。あなたの場合、複数のシステムが相互接続されています。このような場合、イベントはシステム間イベントであり、ドメイン イベントではありません。

したがって、サブシステム間の関係に応じてイベントを発生させます。各ドメイン (サブシステム) の観点から見ると、他のサブシステムは統合レイヤーであり、おそらく内部に独自のドメイン モデルがあります。

したがって、あなたの質問に対する答えは次のようになります。

1) いいえ、そのアプローチはシステム統合に完全に関連しているためです。

2) フローの変更には、サブシステムではなく、統合動作の変更が必要です。

もう 1 点: サブシステムとは、サービスと似ています。各ドメインには、相互作用するサービスがあります。また、サービスは通常、対話によって接続されます (複数のサービスを持つ SOA システムは実装例です)。さらに、各ドメインはサービスとしても機能し、おそらくサービス層を通じて公開されます。

于 2013-04-25T16:35:43.750 に答える