🌟

『Architecture for Flow』第2章を読む：戦略的DDDでビジネスの核心を見極める

に公開
DDD
architecture
teamtopologies
wardleymapping
idea

「解決空間に飛び込む前に、まず問題空間を理解せよ。」

Susanne Kaiser の『Architecture for Flow』第2章を読み、 戦略的ドメイン駆動設計（DDD）がなぜ“アダプティブなシステム”の要になるのかを整理しました。

🎯 なぜ戦略的DDDなのか？

第1章で登場した Wardley Mapping は、「いま自分たちはどんな環境にいるのか（Where）」を理解するためのツールでした。
第2章ではそこから一歩進み、「何に集中すべきか（What）」を見極める段階に入ります。

その羅針盤となるのが、戦略的ドメイン駆動設計（Strategic Domain-Driven Design） です。

DDDはもともと、技術の話だけでなく、ビジネスの複雑さを解きほぐすための思考法です。
特に「戦略的DDD」は、 「 ビジネスのどこが競争優位性の源泉なのか 」 を明らかにすることにフォーカスします。

💬 ビジネスと技術の共通言語を築く ― ユビキタス言語

戦略的DDDの出発点は、 ドメインエキスパート（ビジネス側）と開発チームの協働 です。
両者がそれぞれの専門用語を使い続けていては、問題の本質がすれ違ってしまいます。

そこで登場するのが ユビキタス言語（Ubiquitous Language） です。
チーム全員が同じ言葉で会話できるようにすることで、 問題空間の理解を共有し、誤解のない設計につなげる ことができます。

この段階ではコードを書くことよりも、 「 ビジネスの仕組みを正しく言語化する 」ことが重要です。

🧭 3つのサブドメイン ― どこに集中投資すべきか？

DDDでは、ビジネス領域（Problem Space）を3つのサブドメインに分けて分析します。
これは、「どこにエネルギーを注ぐべきか」を明確にするための分類です。

サブドメイン 説明 戦略的位置づけ
コアドメイン（Core Domain） ビジネスの競争優位性の源泉。顧客に独自の価値を提供する領域。 差別化要因。最も多くのリソースを集中させるべき場所。
支援サブドメイン（Supporting Subdomain） コアを支援するが、それ自体は差別化要因ではない領域。 効率化の対象。内製するが、コアではない。
汎用サブドメイン（Generic Subdomain） 認証や決済など、多くのビジネスで共通する機能。 標準化・外部化の対象。自社開発すべきでない領域。

この分類を明確にすることで、 「ビジネス価値 × 技術コスト」のバランスを見ながら戦略的な意思決定が可能になります。

🔗 Wardley Mappingとの連携 ― 「自社で開発するか、外部を活用するか」を地図で判断する

ここで再び Wardley Map が登場します。
第1章で描いたマップは、「市場の成熟度」と「構成要素の進化」を示していました。

著者は、このマップを サブドメイン分類と重ね合わせる ことで、 「 どの領域を自社で開発し、どの領域を外部のサービスに委ねるか 」を判断できると説明しています。

マップ上の位置 意味 戦略的判断
左側（創生期／カスタムビルド） 市場が未成熟で、まだ明確なソリューションが存在しない領域。 自社で開発する領域：独自の価値を築くため、コアドメインとして重点投資する。
右側（製品／コモディティ） 既に市場で標準化され、誰でも安価に利用できる領域。 外部のサービスや既製のソリューションを活用する領域：効率を優先し、差別化しない。

この組み合わせにより、 感覚や経験ではなく、データと地図に基づいた戦略的判断 が可能になります。

💡 つまり、Wardley Mapping が「市場の地図」を描き、 DDD が「ビジネスの重心」を定める。
この2つが重なる地点こそが、真に価値ある投資対象です。

🧠 問題空間から解決空間へ ― アダプティブな設計の第一歩

DDDは単なるモデリング手法ではなく、 ビジネス構造を理解し、それをアーキテクチャに反映するための戦略思考 です。

Wardley Mappingで「何に取り組むべきか」を見極め、DDDで「それをどのように形にするか」を設計する。

これが Architecture for Flow の中核的アプローチです。

🌱 学びのまとめ

第2章のキーメッセージを一文でまとめるなら、こうです。

「アダプティブなシステムを作るには、まずビジネスの核心を理解せよ。」

  • DDDは技術設計の前に「ビジネス構造を理解するためのフレームワーク」。
  • サブドメイン分析で「どこに集中すべきか」を明確化できる。
  • Wardley Mapと組み合わせることで、「自社で開発するか、外部を活用するか」を客観的に判断できる。

🧩 次回予告 ― Bounded Contextでソリューション空間をデザインする

次章では、戦略的DDDの理解をもとに、 Bounded Context（境界づけられたコンテキスト） を使ってソリューション空間を設計していきます。

💬 問題空間で見極めた戦略を、アーキテクチャの形に落とし込む。
第3章では、ドメインモデル、コンテキストマップ、チーム間連携といった具体的設計手法に踏み込みます。

📘 関連リソース

🪶 “Understand the problem space deeply before designing the solution space.”
— Susanne Kaiser, Architecture for Flow

Discussion