BT

ドメイン駆動設計のコンテキスト境界間でデータを共有する

| 作者: Jan Stenberg フォローする 34 人のフォロワー , 翻訳者 吉田 英人 フォローする 0 人のフォロワー 投稿日 2014年12月15日. 推定読書時間: 2 分 |

原文(投稿日:2014/11/25)へのリンク

ドメイン駆動設計(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のようなキューシステムを組み込むことの問題点について書いている。

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには InfoQアカウントの登録 または が必要です。InfoQ に登録するとさまざまなことができます。

アカウント登録をしてInfoQをお楽しみください。

あなたの意見をお聞かせください。

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする
コミュニティコメント

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

ディスカッション

InfoQにログインし新機能を利用する


パスワードを忘れた方はこちらへ

Follow

お気に入りのトピックや著者をフォローする

業界やサイト内で一番重要な見出しを閲覧する

Like

より多いシグナル、より少ないノイズ

お気に入りのトピックと著者を選択して自分のフィードを作る

Notifications

最新情報をすぐ手に入れるようにしよう

通知設定をして、お気に入りコンテンツを見逃さないようにしよう!

BT