実践ドメイン駆動設計 第8章メモ

実践ドメイン駆動設計

実践ドメイン駆動設計 (Object Oriented Selection)

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

エリック・エヴァンスのドメイン駆動設計

• ドメインイベントとはなんぞや
  • 実はエヴァンスのドメイン駆動設計が出た後に出てきた
  • 「ドメインエキスパートが気にかける何かのできごと
    • 「知らせて欲しい」「通知して欲しい」が出てきたらイベントっぽい
  • ビジネスの状況からイベントが必要になる場合も、チームをまたがった議論で認識する場合もある
    • 別の境界付けられたコンテキストに通知する場合
• 結果整合性
  • 途中の過程ではあってないけど、最終的には合わせる
  • 通知したイベントの到着順がテレコになる場合などはどうするんだろうか？ そもそも順序が必要となるような設計をしないほうが正しい？
• トランザクションはアプリケーションサービスで行う
  • ドメインモデルはトランザクションもってはいけない（それは関心ごとではない）
  • この場合だと、オブザーバパターンでパブリッシャーとサブスクライバは同スレッドの中で動く
  • 非同期だと、同じデータソースにアクセスできるようにするか2相コミットが必要
• イベントの発行箇所はいくつか方法があるので、適切に選ぶ
  • 集約から飛ばしたり、パブリッシャーはいろいろ
• イベントに一意な識別子を割り当ててもいい
  • イベントをリポジトリに保存することも出来る
  • この場合だとリポジトリとメッセージング基盤で同じデータソースにアクセスできるようにするなど、齟齬が生じないようにする必要がある
• リモートの境界づけられたコンテキストに通知する場合は、ドメインモデルとメッセージング基盤が同じ永続化ストアにアクセスできるか、2相コミットするか イベントストアを使う必要がある
  • イベントの遅延が発生することがあるので、どの程度許容できるか知っておくこと
  • この本ではイベントストアを使う
• イベントストア
  • 単一の境界づけられたコンテキストないのすべてのドメインイベントを収容
  • ドメインイベントのキューとして使用
  • RESTベースのイベント通知、履歴、分析予測を行うもとになる
  • 集約のインスタンスの再構築 => イベントソーシングの一環
    • つまり元データ+イベントから、現在の集約の状況を作り出すということになる
    • ここから履歴消して、変更をロールバックしたり出来る
    • 再生成した集約の永続化はどこかの時点でやるのかな？ この本には特に書かれていないように見える
• イベントストアから他に転送する場合(リモートの境界づけられたコンテキストにも適用できる？)
  • RESTfulなリソース
    • 多数のクライアントが既知のURLからデータを取ってくる（Pullモデル）
    • プロデューサーが複数だとつらい
    • データとってきたほうは、自身のコンテキストに合わせて集約なりを作る（ある種のリポジトリ？）
  • メッセージング基盤を使う
    • RabbitMQのようなミドルウェア
    • RESTでやっていたような処理をミドルウェアにまかせてしまえる
    • メッセージを受け取った側でそのメッセージを処理する責務を追う、メッセージングミドルウェアは送達保証の責務のみ
• メッセージの重複配送
  • サブスクライバ（クライアント）のドメインモデルに対する操作が冪等になるようモデリングする（実装する）
  • もしくはサブスクライバ/レシーバ自体が冪等になるように設計（重複は処理しないようにする）
    • サブスクライバの永続化メカニズムの中に記録用の場所を確保、処理済みか保存する
  • RESTベースだと重複の排除を気にする必要があまりない