ドメインで発生する出来事を表すドメインイベントは、Eric Evan氏がそのオリジナルのDDD本を発表したときは、ドメイン駆動設計(DDD)パターンには含まれていなかったが、今やドメインモデルの戦略的要素として含まれている。結果整合性はスケーラビリティと性能を改善するための設計手法であり、ドメインイベントはこの設計を達成するためにドメインの情報を運ぶトリガーとして働く、とFlorin Preda氏は最近のブログで書いている。
トランザクションで一貫を保つワークフローは、ほとんどの開発者にとって親しみのあるものであり、あるシステムでクライアントが実行したコマンドはひとつのトランザクションの中で、ドメインの一貫性を維持するのに必要なすべての処理を実行する。すべての処理が成功すしたにしろ、失敗したにしろ、中間的な状態はない。
結果整合性のワークフローは、分散システムで一般的であり、クライアントがあるシステムでコマンドを実行すると、ドメインの一貫性を維持するのに必要な処理の一部しかトランザクションで実行されない。残りの処理はその後、しばらく経ってから実行される。そして、システムは一貫した状態になる。
Preda氏は、トランザクションで一貫性を確保するほうが直接的で簡単だが、結果整合性のほうが利点がある場合もある、と考えている。ある処理Aのあとに別の処理Bを実行する場合、次のような4つのシナリオが考えられる。
- 処理Bが実行に長い時間がかかる。
- 処理Bは本来、非同期。例えば、非同期の仕組みに依存している。
- 処理Bは処理Aとは異なる集約に対して行われるが、境界コンテキストは同じ。
- 処理Bは処理Aと違う境界コンテクストで実行される。
Preda氏にとっては、シナリオ3とシナリオ4は、ドメイン駆動設計(DDD)と関係があり、このふたつは結果整合性が従来のトランザクションよりも優れた設計になると考えいてる。ここでドメインイベントが役に立つ。ドメインイベントはドメインで発生した出来事の表現であり、ワークフロー内で次のステップを始めるためのトリガーとして働くことで結果整合性を促進し、必要なドメインの情報を運ぶ。
Mike Mogosanu氏は、実際の世界では、トランザクション一貫性のワークフローのほうが珍しい、と主張する。ビジネスのプロレスは通常、いくつかのユースケースのつながりであり、Unit of Work (UoW)パターンを使って複数の変更を永続化するのは、ナイーブな解決策で、技術的な観点から複雑になってしまう。特に分散アプリケーションの場合は顕著だ。
Mogosanu氏は複数の境界コンテキストに関わるビジネスプロセスはコンテキストごとのひとつのドメインのユースケースで結果整合であるべきだと考えている。ドメインのユースケースは、集約の一貫性を保つことに責任があり、この場合、UoWパターンは有用だ。また、他のユースケースを始めるドメインイベントを発行することで、システム全体の一貫性を保つことにも責任を持つ。
氏は自身のアイディアを示すために、Vaughn Vernon氏の著書Implementing Domain-Driven DesignのシンプルなバージョンのアプリケーションをC#で、Azure Service Busを使って作っている。