認識がそろうチームほど「決めないこと」を書き残す　イベントストーミングが議論の熱量に流されない理由

ソフトウェアデザイン

　ソフトウェアデザインでは、散らばっている同じ集約をひとまとまりに整理してメソッドとイベントの設計書として確定させ、その上でコンテキストの境界を見つけて独立したビジネスの文脈ごとに設計を分離します。まずは前者のステップとして、集約ごとに要素をまとめる作業から進めます。

集約をまとめる

　集約の命名を終えたら同じ集約をまとめていきます。各種コマンドとイベントをひとつの集約の周りに配置していくということです。

　たとえば在庫集約の周りには「在庫を予約する」「在庫を確保する」といったコマンドと、在庫数に応じた「在庫が確保された」「在庫が確保できなかった」というイベントが集まります。これがそのまま集約の設計書となり、コマンドハンドラとして何を定義し、どのイベントを送出するのかが示されます。

コンテキストの発見

　集約を整理できたら、次はコンテキストの境界を見つけていきます。境界づけられたコンテキストは共通の言語と文脈のもとで、特定のドメインモデルを適用する範囲を示します。各コンテキスト間の連携はイベントを通じて行われ、たとえば注文を扱うコンテキストから「注文が確定された」イベントが発行されると、在庫を扱うコンテキストはそれを受けて在庫の確保を行います。このようにコンテキスト間の依存関係も明らかになっていきます。

　注文システムでは次のようなコンテキストが見えてきます。注文管理コンテキストは注文のライフサイクル全体を管理し、在庫管理コンテキストは商品の在庫状態を扱います。決済コンテキストは支払い処理に特化し、配送コンテキストは配送に関する処理を担当します。また発送通知のような顧客とのコミュニケーションは通知コンテキストとして分離できます。

　コンテキストの定義には絶対的な基準はなく、チームで合意できるグルーピングを見出します。イベントストーミング図ではこれらのコンテキストを線で区切って表現します（図9）。

線で区切られた境界づけられたコンテキスト

残しておくべき図について

　ここまでの進め方では、ビッグピクチャーの図にコマンドや集約などを加えてビジネスプロセスモデリングを進め、ソフトウェアデザインでは付箋を集約ごとに並べ直します。同じ図を更新していくため、各フェーズの図が別々に残るわけではありません。

　ビジネスプロセスモデリングの図は開発者とビジネスサイドのメンバーが出来事の因果関係や処理の分岐を話し合う際に役立ちます。そのためにこの図も残しておきたい場合は、ソフトウェアデザインに進む前に図を複製しておく方法があります。一方、ソフトウェアデザインの図は集約を実装したり、コンテキストに沿ってチームの担当範囲を検討したりする際に役立ちます。

　両方を更新し続けられる体制があれば、それぞれの用途に合わせて維持する価値があります。ひとつに絞るなら、私はビジネスプロセスモデリングの図を残します。ビジネスサイドとの議論に使えるうえ、この図をもとに実装することもできるからです。

今回の抜粋記事はここまでです。続きは書籍を確認いただけますと幸いです。ぜひ11月26日の発売日に書店でお手に取ってみてください。

 

Amazon　 SEshop　 その他

 

CQRS+ES実践ガイド イベント駆動型モデリング／システム構築手法

 

著：成瀬 允宣
発売日：2026年11月26日（木）
定価：4,620円（本体4,200円＋税10%）

本書について

本書はCommand Query Responsibility Segregation（CQRS) と Event Sourcing（ES）という2つのアーキテクチャパターンを活用し、拡張性と保守性に優れたシステム設計の実現手法を解説した書籍です。基礎的な概念から応用的なパターンまで、段階的な説明で理解を深められる構成となっています。