前回の記事
【ミライトデザイン社内勉強会#16】「IDDD本から理解するドメイン駆動設計」輪読会~第7章「ドメインサービス」~ - Qiita
実践DDD本 第8章「ドメインイベント」～出来事を記録して活用～ (1/3)：CodeZine（コードジン）
ドメインイベントがどんな時に必要になるのかが、イメージがわかない。重要なイベントはドメインイベントにしといた方がメリットあるよって話？
- 複数の集約の操作をしたい時とか（トランザクションをまたいだ処理）
- メール送信とか複数の人に送ると意外と時間がかかるので、イベントに切り出して、別のサーバーで実行するとか
- 一般的なシステムは××が起きたから〇〇をするっていう作りになっている
- ドメインイベントは××が起きたまでを管理している
- 結果整合性を用いたシステムを作る時に役にたつ
- 例えば、××が起きた時（イベントがあった時）にはAとBを更新するって処理があった時に、ドメインイベントとしてイベント分離されているとA、B以外のCの処理を追加したい。ってなった時に楽に追加することができる
- ドメインイベントは××が起きたまでを管理している
- 結果生合成を保つ目的であればドメインイベントを使用しなくても実装は可能。
- トランザクションを広げる。
- しかし、トランザクションは単一の集約に対して変更することを推奨している為、ドメインイベントを作成することでトランザクションを分散することができる
他システム（他の境界づけられたコンテキスト）とのイベント送受信で１と３の違いがいまいちわからない
- 1メッセージ基盤を直接ドメインイベントが利用しているが、3はイベントは同じデータ領域に保存するが、メッセージ基盤は外部にある
- 3は
イベントストアのイベントをメッセージ基盤に転送する仕組みが必要ここを２フェーズコミットでやると2と同じになりそう - 一番楽に実装できるのは1
- ただ柔軟性にかけるかも
- 2は1に柔軟性を求めたもので
- 3は2の問題点を解消しようとしたものだと思う
メッセージ基盤
- メッセージだけを責務とした基盤
- A、Bというインスタンスがあったらそのやりとりを仲介する基盤
- メッセージというのはキューであったりイベントであったり決まりはない
ユースケースで複数の集約を操作する場合にイベントをトリガーに処理を分けようってこと？
- ドメインイベントを発行するユースケースで行うのはドメインイベントの発行まで
- ドメインイベントを受け取ってその後どうするかは、責務が別になる（ドメインイベントを受け取った側が考える）
次回
【ミライトデザイン社内勉強会#18】「IDDD本から理解するドメイン駆動設計」輪読会~第9章「モジュール」~ - Qiita