ドメイン駆動設計(Domain-Driven Design/DDD)を使って大規模システムの関心事を，それぞれ独自のデータストアを使用するコンテキスト境界{Bounded Context)に分離していると，共通的なデータを共有する必要が生じることが少なくない – Julie Lerman氏は先日のMSDN Magazineで，このように説明した。
2003年にMicrosoft MVPを獲得している氏は，DDDについて学び始めた頃，このような分離の結果として生じるデータの重複に苦慮していた。しかし，オリジナルのDDD書籍の著者であるEric Evans氏の説明が，すべてを明解にしてくれたという。
複雑性の対価を払う場所を選択しなければなりません。DDDはソフトウェアの複雑性を減じるものですから，その結果としてモデルの重複，あるいはデータの重複に対しても代償を払うことになります。
コンテキスト境界がそれぞれ独自のデータベースを所持するような構成で，共通データを利用するには，さまざまな方法がある。氏はその中から，ひとつの方法を選択した。一方のシステムがデータベースを編集し，もう一方はデータを部分的に読み取り専用でアクセスする構成で，ひとつのコンテキスト境界のデータを別のものにミラーリングする方法だ。
氏は例を挙げて，そのシナリオを説明した。ユーザサービスを処理するSystem Aというシステムがあり，ユーザ情報を含む多数のデータをメンテナンスする。もうひとつ，オーダを処理するSystem Bというシステムが，ユーザの名前とIDを参照するためにのみ，そのデータを読み取りアクセスする。
System Bがユーザ情報の生成と更新を行うメソッドを公開する方法では，System Aがそれを使用する場合に同期依存性が発生することになる。それに代えて氏が使用したのは，メッセージキューを使ってパブリッシュ・サブスクライブパターンを実装する，イベントベースのアプローチだ。この方法でのSystem Aは，ユーザ情報の生成および更新に関するメッセージを送ることでイベントを発行(パブリッシュ)する。System Bがそのメッセージを受信し，データベースの更新を行う。このテクニックを使うことで，System Bは全ユーザのリストを保持することになるが，所有するデータの量はSystem Aに比較して少なくなる。
氏はこのような，非同期的な方法によるメッセージ転送を行うシステムを，メッセージ格納および送信インフラストラクチャ，操作用のAPIを含めて，イベントバスと呼んでいる。氏の例では，オープンソースのメッセージキューであるRabbitMQを使用している。
氏が自身の例を実装したコードは，ダウンロードにより入手可能である。
Udi Dahan氏は，2012年のブログ記事でトランザクションについて取り上げ，システムの不整合を回避する手段として，データベーストランザクションにRabbitMQのようなキューシステムを組み込むことの問題点について書いている。