🐡

『Architecture for Flow』第3章を読む：Bounded Contextでソリューション空間をデザインする

に公開
DDD
eventstorming
architecture
wardleymapping
contextmap
idea

「問題空間を理解したら、次はそれをどう形にするか。」

Susanne Kaiser の『Architecture for Flow』第3章を読み、 戦略的DDDによるソリューション空間の設計を整理しました。

🎯 目的 ― 戦略を設計へつなぐ

第2章では、 戦略的ドメイン駆動設計（Strategic DDD） を使って、ビジネスの「問題空間（Problem Space）」を分析しました。

第3章では、その理解を 「ソリューション空間（Solution Space）」に落とし込む ことがテーマです。
つまり、戦略を実際のアーキテクチャ設計に結びつける段階です。

著者はここで、アダプティブなシステムを実現するための鍵として、 境界づけられたコンテキスト（Bounded Context） を提示しています。

🧩 境界づけられたコンテキストとドメインモデル

ドメインモデルとは？

ドメインモデルは、特定のビジネス領域に関する知識やビジネスルールを抽象化したものです。
モデルは ユビキタス言語（Ubiquitous Language） に基づいて構築され、ドメインエキスパートと開発者が同じ概念を共有するための“知識の形”です。

境界づけられたコンテキストとは？

Bounded Contextは、そのモデルが どこで、どの意味で有効か を定義する境界です。
これは単なる技術的スコープではなく、

  • 言語的な境界（用語の意味）
  • 所有権の境界（誰が責任を持つか）
  • 物理的な境界（デプロイやコードベースの単位）
    を同時に表します。

🧠 モデリング手法 ― チームでソリューションを描く

境界づけられたコンテキストを設計するには、
チームが協働してドメインを可視化するための 協働モデリング手法 を活用します。

手法 概要 目的
Event Storming ドメインイベントを洗い出し、業務フローを可視化。 システムの動的なふるまいを理解する。
Domain Storytelling アクター（登場人物）の視点から物語形式で業務を表現。 チーム間の共通理解を深める。
Example Mapping 例・ルール・質問を使って受け入れ基準を整理。 ビジネスルールの曖昧さを減らす。
User Story Mapping ユーザーの行動を軸にストーリーを並べる。 顧客体験を起点とした機能設計に役立つ。

これらの手法は、ドメインモデルを“机上の理論”ではなく、 チームで育てる設計資産 に変えます。

🔗 戦略的連携 ― Wardley Mappingとの接続

第1章・第2章で扱った Wardley Map は、市場の成熟度や構成要素の進化を示す“環境の地図”でした。
第3章では、設計されたコンテキストを マップ上の進化ステージ と対応付けます。

Wardley Map上の位置 意味 設計上の示唆
創生期（Genesis）／カスタムビルド（Custom-Built） 新しい価値を生み出す未成熟領域。 コア・ドメイン：自社で開発すべき領域。
製品（Product）／コモディティ（Commodity） 標準化・成熟した領域。 汎用サブドメイン：外部サービスを活用する領域。

これにより、 戦略（Wardley Mapping）と設計（DDD） の整合性が取れるようになります。
特に、頻繁に変化するコア領域では、 コンテキストの独立性と適応性 を重視します。

⚙️ モジュール性とコンテキストマップ

変化に強いアーキテクチャを作るには、 「コンテキスト内では高凝集、コンテキスト間では疎結合」 を実現する必要があります。

コンテキスト同士の関係は、 コンテキストマップ（Context Map） で可視化されます。

主要な関係パターンには次のようなものがあります。

パターン 略称 特徴
Separate Ways SW 独立して進化する。結合を避ける。
Published Language PL 公開された契約に基づいて連携。
Anticorruption Layer ACL 外部システムの影響を隔離。
Conformist CF 相手のモデルに従う。
Open-Host Service OHS 他者が利用できるAPIを提供。
Shared Kernel SK 共通の小さなモデルを共有。
Partnership PS 双方が協調して進化。
Big Ball of Mud BBoM カオスな依存。避けるべき。

🧱 DDDとWardley Mappingの原則の接続

著者は、DDDの設計原則が Wardley MappingのDoctrine（教義的原則） を具現化していると指摘しています。
例えば：

Wardley Doctrineの原則 DDDの設計原則との対応
Focus on user needs ユビキタス言語でユーザー価値を中心に設計。
Use appropriate methods サブドメインごとに最適な技術選択をする。
Think small, as a contract Bounded Context単位で責任と契約を定義。

このように、戦略・設計・実装が一貫した形で結びつくことこそが、 アダプティブなアーキテクチャ を生み出します。

🌱 学びのまとめ

第3章の要点を一言でまとめると：

「境界を正しく引くことが、変化に強いアーキテクチャを生む。」

  • Bounded Contextは、ドメインモデルの整合性を保つための“言語的・意味的な境界”。
  • コンテキストマップを使うことで、チーム間の結合関係を明示できる。
  • DDDの原則は、Wardley MappingのDoctrineと整合する。
  • 高凝集・疎結合のモジュール性こそが、適応性を支える。

🧩 次回予告 ― 戦術的DDDでドメインモデルを実装する

次章では、ここまで設計してきたソリューション空間を、 Tactical Domain-Driven Design（戦術的DDD） を用いて実装していきます。

💬 エンティティ、値オブジェクト、アグリゲート、ドメインイベントなど、戦術パターンを通して“流れを保つコード設計”を探ります。

📘 関連リソース

🪶 “Boundaries define the flow of change.”
— Susanne Kaiser, Architecture for Flow

Discussion