DDDの戦略的設計を、意思決定のロードマップとして学ぶ。
研修概要
DDD戦略的設計 実践は、ドメイン駆動設計（DDD）の戦略的設計を「整理→境界→連携→組織」という意思決定のロードマップとして体系的に学ぶ研修プログラムです。ドメインの蒸留・ユビキタス言語の定義・境界づけられたコンテキストの設計・コンテキストマップによる連携設計・コンウェイの法則に基づく組織設計までを、ECサイトを題材とした一貫した事例で習得します。
実装パターン（タクティカル設計）は扱わず、意思決定・投資判断・組織への接続に特化することで、Java・C#・TypeScript混在チームのエンジニア・アーキテクト・マネージャー・CTOが同じ場で受講可能です。組織全体の設計語彙を揃え、技術設計と組織設計を同じ視点で議論できる環境を構築させます。
こんな課題を持つ企業におすすめ
ビジネス現場
- 機能変更のたびに複数チームの調整が必要となり、「誰の承認が必要か」が曖昧なままリリースが停滞している
- 「受注」「顧客」「在庫」など同じ言葉がチームによって違う意味で使われ、仕様書の誤読と手戻りが繰り返されている
- エンジニアの「技術的負債の解消」が経営層に伝わらず、投資優先順位の議論が噛み合わない状態が続いている
- 設計の全体像が特定エンジニアの暗黙知に閉じており、新メンバーのオンボーディングに毎回長時間を要している
本研修の到達目標
開発現場
- 1戦略的設計を意思決定の方法として理解する設計テクニックの寄せ集めではなく、整理→境界→連携→組織の順序で設計判断を組み立てられるようになります。
- 2DDDの設計思想（判断の軸）の理解を深めるドメイン蒸留・ユビキタス言語・境界づけられたコンテキスト・コンテキストマップを、なぜそう決めるかの根拠とともに説明できるようになります。
- 3設計判断の根拠を揃えてチームで会話できる状態をつくる同じ言葉・同じ判断軸でマネージャーと現場が会話できるようになり、設計レビューや仕様議論での手戻りを減らします。
組織への期待効果
- 1新機能リリースの遅延・コスト超過の抑制変更の責任範囲が明確になることで、複数チームを巻き込む調整待ちとリリース渋滞を構造的に防ぎます。「誰の承認が必要か」の曖昧さが解消され、意思決定のリードタイムを短縮します。
- 2投資判断の精度向上と経営・現場の対話促進コアドメインの特定とドメインビジョンの言語化により、「技術的負債 vs 新機能」の議論を経営とエンジニアが同じ基準で行えるようになります。予算配分の説得力と意思決定スピードが高まります。
- 3設計属人化による事業継続リスクの低減設計判断の根拠が言語化・共有されることで、担当エンジニアの異動・退職があっても開発が止まらない体制を確立します。オンボーディングコストの最小化にも直接寄与します。
本研修の特長
「なぜその境界か」を言語化できる意思決定の体系
設計テクニックの寄せ集めではなく、意思決定の順序を持った知識体系として整理した構成は市場でも極めて希少です。整理→境界→連携→組織の4区分に沿って学ぶことで、設計判断の根拠をチームで共有・説明できるようになります。
一貫したEC業務例で、抽象概念を実践的に理解する
ドメインの蒸留からコンテキストマップ・組織設計まで、ECサイトという単一の業務例を全章通じて使用します。「同じ名前でも意味が違う」というDDDで最も理解しにくい概念も、バケツ図などの図解で直感的に習得できます。
言語非依存だから、混在チームのエンジニア・マネージャーが一緒に受講できる
Java・C#・TypeScript混在チームにも提案できる唯一のコースです。実装パターンを扱わないため、エンジニアだけでなくアーキテクト・テックリード・マネージャー・CTOも同じ場で受講でき、組織全体の設計語彙が揃います。
研修カリキュラム
| 日程 | 章・学習テーマ | 学習内容・習得スキル |
|---|---|---|
| 午前 | 第1章：戦略的設計の全体像 | 戦略的設計を「意思決定の順序を持った知識体系」として理解します。整理→境界→連携→組織の4区分をロードマップとして把握し、以降の学習の全体像を掴みます。 |
| 第2章：問題空間を理解・整理する | ドメインの蒸留（業務領域を分けて整理）を学びます。コアドメイン・支援領域・汎用領域の判断基準を理解し、ドメインビジョンとコアドメインチャートで投資すべき領域を説明できるようになります。 |
|
| 第3章：言語とモデルの一貫性を保つ | ユビキタス言語・ドメインモデルの抽出・境界づけられたコンテキストを学びます。「同じ言葉＝同じ判断」が成立する範囲を切り、判断の一貫性を守る構造の設計方法を習得します。演習1（システム境界の可視化）を実施します。 |
|
| 午後 | 第4章：コンテキスト間の関係を設計する | コンテキストマップと関係パターン（パートナー・顧客/供給者・順応者・共有カーネル・別々の道）を学びます。ACL・OHS・公開言語を使った連携方針の合意と、変更影響の局所化手法を習得します。演習2（システム間関係の可視化）を実施します。 |
| 第5章：戦略的設計と組織を結びつける | コンウェイの法則・チーム＝コンテキスト・責務と意思決定の分離を学びます。境界を「誰が決めるか」として固定し、変更が速くなる組織設計の考え方を習得します。演習3（システム分割状況の点検）を実施します。 |
|
| 参考：マイクロサービスのアンチパターンとDDDによる解決策 | 分散モノリス・分散トランザクションの課題・フロントエンドのモノリス化の3つのアンチパターンを解説します。時間に応じて取捨選択可能な補足セクションです。 |
必要な受講環境と前提知識
受講環境
本研修は講義・ディスカッション・演習を中心とした構成です。特別な開発環境は不要です。以下の環境をご用意ください。
| PC・OS | Windows 11 ／ macOS（どちらでも可） |
|---|---|
| ブラウザ | Google Chrome ／ Microsoft Edge ／ Safari（最新版推奨） |
| 描画ツール | draw.io（無料・ブラウザで利用可）／ コンテキストマップ・ドメインモデルの作図演習に使用 |
| ドキュメント | Microsoft Word ／ Google Docs（ユビキタス言語・ドメインビジョンの記述演習に使用） |
| ホワイトボード | 物理またはオンライン（Miro・FigJam等）／ ディスカッション演習に使用 |
前提知識
- 開発経験・基礎知識：任意の言語（Java・C#・TypeScript等）を用いたソフトウェア開発の実務経験があること。オブジェクト指向プログラミングの基本概念（クラス・インターフェイス・継承）とREST APIの基本概念を理解していること。
- システム設計の基礎知識：レイヤードアーキテクチャ（プレゼンテーション層・ビジネスロジック層・データ層）の概念とリレーショナルデータベース（RDB）の基本概念を理解していること。
- あると望ましい知識（推奨）：DDDの戦術的設計（Value Object・Entity・Repository）の基礎概念、マイクロサービスアーキテクチャの概念的な理解、チーム開発・アーキテクト・マネージャーとしての実務経験。
お問い合わせ
本研修に関するご質問・お申し込みは、以下のフォームよりお問い合わせください。
担当者より2営業日以内にご連絡いたします。