🐙戦略的DDDをどう始めるか——IDDDから学ぶ実践プロセス
戦術から入ると迷子になる
DDDを学び始めると、集約・値オブジェクト・リポジトリといった戦術パターンに目が向きやすい。コードに直結するから当然だ。
しかし戦術パターンを学んでも「どこに使うか」がわからないと意味をなさない。集約をどこで切るか、どのクラスがエンティティでどれが値オブジェクトかは、ドメインを理解していなければ判断できない。
IDDDのVaughn Vernonが1〜2章で戦略的DDDを先に説く理由はここにある。
“Strategic Design is so important because without it, your DDD effort will be on shaky ground.”
戦略的DDDとは「何を作るか・なぜ作るか」を整理することだ。戦術は「どう作るか」。順番を間違えると戦術パターンは道具箱に並んだまま使われない。
4つのステップ
IDDDの枠組みを実践に落とし込むと、以下の4ステップになる。
Step 1: ビッグピクチャーを描く
Step 2: イベントストーミングで知識を引き出す
Step 3: Bounded Contextの境界を引く
Step 4: コンテキストマップで関係を整理するこれらは順序通りに進むものではなく、繰り返しながら精度を上げていく。最初は荒くていい。
Step 1: ビッグピクチャーを描く
最初にすることは、システム全体ではなくビジネス全体を俯瞰することだ。
組織が何で収益を上げているか。競合に対してどこで優位に立っているか。それがわかれば「コアドメイン」の輪郭が見える。
DDDではサブドメインを3種類に分類する：
| 種類 | 判断基準 | 対応 |
|---|---|---|
| コアドメイン | ここが強いから勝てる | 最高人材・最大投資 |
| サポートサブドメイン | 必要だが差別化でない | 自前実装・適切な投資 |
| 汎用サブドメイン | どの会社でも同じ | SaaS・OSS |
この分類は設計の話ではなく、リソース配分の意思決定だ。コアに集中するために、他は意図的に手を抜く判断ができる。
やってみる
ホワイトボードに「うちの会社が提供しているもの」を箇条書きする。そのうち「これがないと競合に負ける」と感じるものがコアドメインの候補だ。最初は仮決めでいい。進むうちに見えてくる。
Step 2: イベントストーミングで知識を引き出す
コアドメインの候補が見えたら、そのドメインを深く理解する必要がある。ここで有効なのがイベントストーミングだ。
イベントストーミングはドメインエキスパート（業務の専門家）と開発者が同じ場に集まり、付箋を使って業務イベントを書き出すワークショップだ。
ルール
- イベントは過去形・受動態で書く（
注文が確定された、決済が承認された） - 「なぜそれが起きるか」ではなく「何が起きたか」に集中する
- ドメインエキスパートが使う言葉をそのまま使う
なぜ過去形か
過去形で書くことで「起きた事実」として扱える。システムがどう動くかではなく、ビジネスで何が起きるかを中心に置くためだ。
イベントストーミングを通じて出てきた言葉がユビキタス言語の素材になる。これをコードの変数名・関数名・クラス名に使う。ドキュメントと実装が同じ言葉を使うようになると、「コードを読めば仕様がわかる」状態に近づく。
Step 3: Bounded Contextの境界を引く
イベントストーミングでドメインの全体像が見えてきたら、Bounded Contextの境界を引く。
Bounded Contextとは「同じ言葉が同じ意味を持つ範囲」だ。逆に言えば、言葉の意味が変わるところが境界のヒントになる。
境界を見つける手がかり
言葉の意味の変化
「顧客」という言葉が、営業部門では「見込み客を含む広義の顧客」を指し、経理部門では「請求書を送る相手」を指すなら、そこに境界がある可能性が高い。
データの変更頻度の差
商品カタログと在庫数では更新頻度が全く異なる。同じContextに入れると互いの変更が干渉しやすい。
チームの責任範囲
コンウェイの法則が示す通り、システムの構造はチームの構造を反映する。境界を引くときはチームの責任範囲と合わせると、後の摩擦が少ない。
初期段階での心構え
最初から完璧な境界は引けない。ドメインへの理解が深まるにつれて境界は修正される。IDDDはこれを「継続的なモデリング（Continuous Modeling）」と表現している。
完璧を目指して動き出せないより、荒い境界で始めて学びながら修正する方がよい。
Step 4: コンテキストマップで関係を整理する
Bounded Contextが複数できたら、それらの関係を可視化する。これがコンテキストマップだ。
コンテキストマップは9つの統合パターンで構成されるが、まず押さえるべきは「上流・下流の関係」だ。
[注文コンテキスト] ──→ [在庫コンテキスト]
上流 下流上流は下流に影響を与える。下流は上流の変更に追従しなければならない。この関係を無視すると、チーム間の摩擦が増える。
典型的なパターン
顧客と供給者（Customer-Supplier）
上流チームが下流チームの要求を優先度に組み込む。権力関係が明示的で協調的。
腐敗防止層（ACL）
外部システムや他チームのモデルが自チームのモデルを汚染しないよう翻訳レイヤーを設ける。外部の変更の影響を受けにくくなる。
順応者（Conformist）
上流の変更にただ追従する。上流に交渉力がない場合の選択肢だが、積極的に選ぶべきではない。
コンテキストマップの使い方
コンテキストマップは設計図ではなくチーム間の会話の材料だ。「このコンテキストは誰が所有しているか」「変更するときに誰に話を通す必要があるか」が明確になる。
形式にこだわらなくていい。ホワイトボードの写真でも、Miroの図でもよい。定期的に見直して現実と合わせ続けることが大事だ。
よくある罠
全部コアドメインにしてしまう
「うちの業務はどれも重要だ」と感じると、全部がコアドメインになってしまう。しかしそれはコアドメインがないのと同じだ。リソースは有限なので、意図的に差をつけることが戦略の本質だ。
Bounded Contextを細かく切りすぎる
マイクロサービスの文脈でBounded Contextを過剰に分割すると、サービス間の通信オーバーヘッドと整合性の問題が爆発する。コンテキストは「チームが自律して開発・デプロイできる単位」であることが前提だ。
最初から完璧なモデルを目指す
IDDDのサンプルシステム（SaaS型Scrumシステム）も、最初から完璧なモデルだったわけではない。モデリングは反復だ。今の理解で最善のモデルを作り、ドメイン知識が深まったら更新する。
まとめ：戦略が戦術を意味あるものにする
戦略的DDDは「どこに何を作るか」を決める作業だ。これがないと戦術パターン（集約・リポジトリ・ドメインサービスなど）は正しい場所に置かれない。
4つのステップを順番通りに完璧にこなす必要はない。荒いビッグピクチャーを描き、イベントストーミングで知識を集め、おおまかな境界を引き、チーム間の関係をマップで整理する。この繰り返しの中でモデルは精錬される。
“Model exploration is a learning process. The more you learn, the more you can refine.” — Vaughn Vernon