実践DDD本 第8章「ドメインイベント」～出来事を記録して活用～

IDDD本から理解するドメイン駆動設計 第8回

イベントストアとは

　イベントストアとは、発生したイベントの履歴をストレージに記録する方法です。格納したイベント情報を利用者に公開することで活用します。利用側は必要に応じてイベント発生元のドメインモデルを取得して、自分の境界づけられたコンテキストに取り込みます。

イベントストアとRESTを用いた他システムへのイベント連携

　イベントストアには、次のようなメリットが備わっています。

• メッセージ基盤を通してドメインイベントを発行するキューとして使用できる
• モデルで発生したイベントを全て履歴として記録できる（調査や監査に利用）
• イベントストアのデータを使って、分析や予測ができる（後から集計が可能）
• イベントを用いてリポジトリの構築を行い、集約の再構築ができる（イベントソーシングにてデータパッチやデバッグも可能）

イベントストアの実装イメージ

　イベントストアの実装例としては、「イベントストア（EventStore）」インタフェースを利用してイベントの履歴情報をストレージへ格納します。イベントストアのストレージはMySQLのようなRDBや、LevelDBのようなNoSQLなどから最適な製品を選択します。どのストレージを選択するにしても、ドメインモデルの情報とイベント履歴の整合性が保たれるように注意します。

イベントストアの実装イメージ

　ストレージには「ストアドイベント（StoredEvent）」クラスをシリアライズした内容が格納されます。これらは「ドメインイベント（DomainEvent）」インターフェースを実装するイベントクラスから変換することができます。

自立型のサービスのメリット

　他の境界づけられたコンテキストと連携する場合、ドメインイベントを用いると「自立型のサービス」になることがメリットとして挙げられます。自立型のサービスとは、他のサービスに依存せずに動作するシステムのことを指します。他のシステム（API／RPC）をリアルタイムに呼び出している場合、それらがダウンしていると、自身のサービスもダウンしたりパフォーマンスが低下したりする問題があります。

　そこで、自システムから外部システムを呼び出すのではなく、外部システムから自システム（イベント通知用REST API）を定期的にポーリングをしてもらうことでシステムの独立性を保つようにします。このような連携方式では、イベントを利用する外部システムが増えたとしても、イベント発行側にて変更しなくて良いメリットがあります。

RESTによる通知API

　イベント通知用のREST設計では、最新ログ（カレントログ）と過去ログ（アーカイブログ）の取得ができるように設計します。イベント数は膨大になるため、全レコードを取るのではなく、クライアント側で範囲を指定できるようにするのが一般的です。また、サーバーの負荷が高くならないようにキャッシュを使うようにします。

メッセージングミドルウェアによる連携方法

　上記ではRESTを用いたイベント通知について紹介しましたが、REST APIの実装をする代わりにメッセージングミドルウェアを使うことも可能です。メッセージングを行うミドルウェアにはActiveMQやRabbitMQ、Akka、NServiceBusといったソフトウェアが存在していますが、IDDDではRabbitMQを用いた例を紹介しています。

RabbitMQを用いたイベントの送受信

　RabbitMQはAMQP（Advanced Message Queuing Protocol）というメッセージングプロトコルに準拠した、オープンソースのミドルウェアです。AMQPとは、キューイングやルーティング（P2Pや出版購読モデル）、信頼性、セキュリティといった機能が定義されているプロトコルです。RabbitMQの場合、サーバーをインストールしクライアントAPIを介してアクセスするだけで、メッセージの登録や取得が可能です。RabbitMQを用いてイベントを送信する例は以下の通りです。

1. イベントストアからイベントを一意な識別子でソートして取得する。
2. 取得したリストを昇順にたどり、それぞれをエクスチェンジに送信する。
3. メッセージの発行に成功したら、そのイベントがエクスチェンジに発行されたことを記録する。

　RabbitMQでは、エクスチェンジ（メッセージを送付する機能）にデータを連携するだけでデータを配信できます。配送方式や配送先の選択はRabbitMQ側で制御できます。

メッセージ基盤を使う時の注意点

　メッセージ基盤を使う時の注意点として、メッセージが重複処理される可能性を考慮しておく必要があります。例えば送信側でメッセージを送信した後で、ドメインモデル側のDBのコミットに失敗してしまうケースがあります。また、配送順番が保証されないことも考慮する必要があります。このような問題に対して、購読側にて複数回取り込んでも問題ないように実装します。通常、メッセージID（イベントID）を使用して、どこまでメッセージを処理したかを記録しておきます。

　最近は、AWSやAzureなどのクラウドサービスでもイベントの送受信機能やキューの機能が提供されています。サーバー管理の手間が不要で使い勝手も良いため、システム連携を行う場合の選択肢に入れてもいいでしょう。それぞれの、機能要件／性能／予算などのバランスから選択してください。

最後に

　以上、本稿ではドメインイベントについて、メリットやモデリング方法などを紹介し、シンプルな連携パターンから、イベントストアやメッセージ基盤を使ってイベントを連携していく方法を解説しました。次回はDDDの「モジュール」について紹介します。

参考資料

• ドメインイベントを設計する（yoskhdiaさん）
• DDD実践（ベスト）プラクティス～ドメインイベントとマイクロサービスと組織の関係～（かとじゅんさん）
• ドメインイベントと結果整合性（InfoQ）
• DDDにおいて、なぜ複数の集約にまたがってトランザクションをかけてはいけないのか
• 集約とトランザクション（Mitsuyuki.Shiibaさん）
• パネル討論：DDDのいま課題はなにか・今後どうなる（QConTokyo）
• Eventual Consistency via Domain Events and Azure Service Bus（英語）
• 悲観もあれば楽観もある「トランザクション」の常識 （@IT）
• 分散トランザクションに挑戦しよう！（オブジェクトの広場）
• RESTに関する疑問に答える（InfoQ）
• 新人プログラマに知ってもらいたいRabbitMQ初心者の入門の入門
• AMQPによるメッセージング（GREE Engineers’ Blog）
• 分散型メッセージングミドルウェアの詳細比較（POSTD）
• MQTTとAMQPと.NET（SlideShaere）
• システム間連携におけるEnterprise Integration Pattern（qiita）
• JBoss Fuseを使い倒す その2：デザインパターン概要編（ThinkIT）