求められた3つの境界 - DDD/CQRS/ESが生まれる必然性 by 清家史郎

マイクロサービス設計でこんな課題に直面していませんか？
「なぜ一方のサービスの変更が、全く関係ないはずの他のサービスまで影響するのか？」サービスAの修正が、なぜか別のサービスBまで壊す。ドメインロジックが散在し、変更の影響範囲が予測できません。
「同じデータなのに、なぜ更新処理は500ms、参照処理は50msと10倍差が生まれるのか？」整合性重視の更新と速度重視の参照では、根本的に異なる最適化が必要です。
「システム障害時、現在の状態は分かるのに、なぜその状態になったかが全く追跡できないのか？」結果だけでは原因究明できず、同じ問題の再発を防げません。

本セッションでは、これらの課題を解決するために現場で「求められた」3つの境界設計を技術的に探求します。

1. 責務の境界（DDD）
   なぜ変更が波及するのかドメインモデル散在による意図しないサービス間結合を、境界付けられたコンテキストで解決する必然性を考察します
2. 処理の境界（CQRS）
   なぜ更新と参照で異なる仕組みが必要なのかトランザクション要件と参照要件の根本的違いを分析し、コマンドとクエリ分離による性能と整合性の両立を検討します。
3. 因果の境界（Event Sourcing）
   なぜ結果だけでなく経緯も必要なのか状態変化をイベント記録することで、システム振る舞いの追跡と分散システムでの因果関係管理を実現する価値を分析します。

なぜその技術が「求められる」のか、問題から出発してDDD/CQRS/ESの組み合わせが生み出す境界設計の必然性について、実装パターンとトレードオフを含めて考察します。

• 対象者
  • マイクロサービス設計に携わるエンジニア
  • アーキテクチャ選択の判断基準を模索する方