3

私の会社では、現在、イベント ソーシングと CQRS を組み合わせた DDD アーキテクチャを使用しています。初期バージョンでは、すべてのコンテキストが他のコンテキストからイベントを受信できるようにしていました。しかし、どのイベントがどこで処理されたかを追跡することが非常に難しくなったため、これはすぐに混乱しました。

私たちの現在のアプローチは、コマンドが他のコンテキストに送信されることのみを許可することです。これはうまく機能しますが、多くのコード オーバーヘッドが発生するようです。例えば：

context A sends a  command to context B, 
which changes the state of a domain model, 
which publishes an event, 
which gets handled by an event handler, 
which sends a command back to context A, 
which changes the state of a domain model, 
which publishes an event, 
which gets handled by an event handler,
which sends a command to context C,
etcetera.

さまざまなコンテキストの多くのドメイン モデル、および別のコンテキストに送信されたコマンドをトリガーする多くのイベントには、多くの同様のデータが含まれています。特に顧客の Web サイトのコンテキストでは、モデルにはロジックや状態がほとんど含まれておらず、Web サイト データベースに対して非正規化できるイベントを生成するためにのみ使用されます。それは機能しますが、イベントの発行がドメイン モデルの唯一の目的であってはならないため、これも適切な方法ではないようです。

私たちのアイデアの 1 つは、CMS をドメイン モデルのように動作させ、コマンドをモデルを介して送信する代わりに直接処理し、結果のイベントを処理することでした。これは、このようなケースを処理する適切な方法ですか? また、コンテキスト間で通信するためのより効率的な方法は他にありますか?

4

1 に答える 1

2

初期バージョンでは、すべてのコンテキストが他のコンテキストからイベントを受信できるようにしました。ただし、どのイベントがどこで処理されたかを追跡することが非常に困難になったため、これはすぐに混乱しました。

これだけでは問題はありません。イベントを介したBC間の通信は、典型的なイベント駆動型アーキテクチャです。イベントの追跡は、コンテキストマップを使用して実行できます。

しかし、あなたの場合、BCのやりとりは過度におしゃべりになっていたようです。これは、最適ではない境界の症状である可能性があります。おそらく境界が細かすぎますか？いくつかのドメインモデルに多くの同様のデータが含まれていることを考えると、それらのドメインをマージする必要があることを示している可能性があります。BCの根底にある原則は、機能的および言語的結束の原則です。密接に関連しているものは互いにくっついています。

コマンドに応答して状態を変更した後、イベントを公開するドメインモデルは、完全に有効なワークフローです。

特にお客様のWebサイトのコンテキストでは、モデルにはロジックや状態がほとんど含まれておらず、Webサイトデータベースに非正規化できるイベントを生成するために使用されます。

これは、CQRS用語でのビュー/プロジェクションのようです。ここでも、何も問題はありません。

現在のアイデアの1つは、CMSをドメインモデルのように動作させ、コマンドをモデルに送信して結果のイベントを処理するのではなく、コマンドを直接処理することでした。

これは重要な観察かもしれません。本格的なドメインモデルは、ビジネスロジックが複雑な場合に意味があります。ただし、ドメインがCMSまたはCRUDのドメインである場合は、ドメインモデルは必要ありません。ただし、イベント駆動型アーキテクチャの残りの部分は引き続き保持できます。

于 2013-02-07T17:51:15.653 に答える