はじめに
本記事は、ドメイン駆動設計（DDD）を実践する中で向き合ってきた課題と、その過程で得られた学びや知見を整理したものです。
DDDは、単なる設計技法やアーキテクチャ選択ではありません。
- 何の価値を扱うのか
- 誰がどの関心に責任を持つのか
- どのようにモデルと実装を連動させ続けるのか
といった、ものづくりの前提そのものに踏み込む活動です。
そのため、DDDに取り組むと「迷い」に直面する場面が発生することが多々あるのではないかと思います。
- 取り組み始めたものの、うまく進んでいる感覚がない
- モデリングはしたが、実装に落ちない
- 境界づけられたコンテキスト(BC)や責務に納得感が持てない
この記事では、そうした状態をDDDという手法が持つ構造的な難しさとして捉え、整理していきます。
DDDとは
DDDの基礎となる3つの原則
エヴァンス本で、DDDの基礎となる原則は次の3つであると述べられています。
- コアドメインに集中すること
- ドメインの実践者とソフトウェアの実践者が、創造的に協働してモデルを探求すること
- 明示的な境界づけられたコンテキストの内部で、ユビキタス言語を語ること
DDDは「設計をきれいにするための技法」ではなく、事業価値や戦略と、ソフトウェアの設計・実装を連動させるための思想と体系的な方法です。
扱うスコープが非常に広い
DDDが難しく感じられる大きな理由のひとつに、スコープの広さがあると考えています。
DDDが扱う範囲は、戦術的な設計に留まりません。
事業戦略・ユーザーへの価値
↓
ドメイン分析
↓
ユビキタス言語の整理
↓
境界づけられたコンテキストのデザイン
↓
戦術的ドメインモデル
つまりDDDでは、戦略的な判断が最終的に コードの変更容易性 にまで影響します。
この「ドメインとソフトウェアを連動させようとする試み」こそが、DDDの強みであり、同時に難しさの源でもあると考えます。
なぜDDDは「迷う」のか
DDDはときに銀の弾丸のように語られますが、実際に取り組むと、難しさが先立ちます。
その理由は、構造的に詰まりやすい側面を持っているからです。
迷いの構造
- 効果（変更容易性）が後から効いてくる
- 初期段階では成果が見えにくく、正しさを実感しづらい
- 「ドメインで駆動できている状態」の定義が難しい
- 終わりのない改善の営みのため、完成条件が曖昧になりがちで、到達感を持ちにくい
- 抽象度が高く、組織や業務によって形が変わる
- 他の事例をそのまま当てはめられない
- ユビキタス言語や対話の時間が確保しづらい
- 忙しいほど、本質的な議論が後回しになる
- 初期モデルに自信が持てず、止まりやすい
- 熟達者がいない状態であるほど、学習が進まず確信を得にくいため迷いが長期化する
DDDは「正解を一度決めて終わる設計手法」ではありません。
不確実性を抱えたまま、学びと発見を繰り返しながら進む設計活動であるため、この前提を踏まえていないと迷いやすくなると感じています。
事例：迷いの場面
実践の中で現れる迷いの事例を3つ整理してみます。
1. 境界のスコープが定まらない
まず、境界づけられたコンテキスト（BC）の定義に関してです。
- どこまでを設計対象にするのか
- 期間的な目標範囲と、将来への配慮の意思決定
これが曖昧なまま進むと、BCが肥大化したり、汎用化しすぎて具体性が失われるといった状態になります。
BCを定義するための判断軸
BCは、状況依存で決まるものですが、判断のための軸は概ね以下のような形に収束するのではないかと思います。
- ビジネス価値・資産性
- 事業にとってどのような強みになるか
- 関心事
- どのような業務の関心/ビジネスルールに向き合うのか
- 更新の整合性・技術的制約
- 一貫性をどこで担保する必要があるか
- 障害の影響
- 不整合が起きたときなど、どこに影響が出るか
- 組織/チーム構造
- 変更サイクルや責務の違い
これらは、後続の集約設計やその他実装判断に大きく影響します。
2. 疎結合にならない
次に、BC間の関係や責務に関してです。
- 他の領域に問い合わせないと進まない場面が多い
- 関連線が多く、循環しているため、自律的に判断できない
といった状態は、境界の切り方や関心の分離が十分でない可能性があります。
関連線が多いこと自体が問題なのではなく、片方向になっているかだったり、最小限の情報で済んでいるかなどを見直す材料として扱うことが重要です。
3. モデリングと実装が連動しない
3つ目は「イベントストーミングはできたが、実装に落ちない」ことです。
可能性として、プロセスの段階が混ざっていることに原因があるかもしれません。
詳しくは次章で説明します。
イベントストーミングの進め方
イベントストーミングとは、業務で起きている事実を起点に関係者全員でドメインを理解し、設計につながる共通認識を作るためのモデリング手法です。
次の2つの段階に分けて捉えると整理しやすくなります。
1. ビジネスプロセスモデリング
- 業務フローを可視化する
- イベントを中心に業務を理解する
- 関係者の認識を揃える
この段階では、網羅よりも理解を優先する意識が大切です。
2. ソフトウェアデザインモデリング
- BCや集約を見つける
- 責務を整理する
ビジネスプロセスモデリングで得た業務理解を、ソフトウェアとして扱える構造に整理する段階です。
この橋渡しとして重要なのが、次に述べる「概念抽出」です。
概念抽出の位置づけ
「概念抽出」は、業務で使われている言葉や出来事を、設計や実装で一貫して扱える「意味のある概念」として言語化するための活動です。
概念抽出の目的
- ユビキタス言語を発見・定義する
- 目的と手段のレイヤーを分離する
- BCの関心を明確にする
集約のデザインは、この概念抽出を進めるための手段として有効です。
集約は「整合性の単位」という強い内部制約を持つため、試しに設計すると、
- 何を守りたいのか
- どの言葉が重要か
が浮かび上がります。
戦術的設計
本記事では、戦術的設計の詳細には踏み込まず、戦略的な判断と実装をつなぐ最小単位として「集約と参照の分離」とモデルと実装を連動させ続けるために「整理しておきたい情報」のみ簡単に触れます。
集約と参照の分離
集約は、「不変条件を守る責務を持つ、整合性を担保する単位」として設計します。
集約に含めないもの
- 参照系（検索・一覧など）
- イベント通知系
- 外部システムとの通信
これらは別の関心として扱うことで、モデルの変更容易性を保つことができます。
参照要件は基本的にアプリケーション層のクエリサービスとして構成し、必要に応じて参照用モデルとして扱い、更新系と分離します。
戦術的ドメインモデル実装に必要な要素
モデルと実装を連動させ続けるために、揃えておきたい情報に触れます。
- イベントストーミング結果
- ビジネスプロセスモデリング
- ソフトウェアデザインモデリング
- ユビキタス言語集
- ドキュメント
- ビジネスルール
- ドメインイベント
- クラス図
- コーディングルール
- ドメインモデル実装のサンプル
- 処理フローパターン
これらは一度に揃える必要はなく、更新され続ける前提の「知」として扱いたい内容です。
AIがもたらす変化
「これまで人がやってきた複雑な取り組みを前提に、AIはどうアプローチできるか」少し考えてみたいと思います。
ここまで述べてきたように、DDDは対話・判断・学習を前提とした活動であり、その難しさは構造的な側面がありますが、
AIは以下のように、DDDを学習と対話を支援する存在として位置づけることができると思います。
- 言葉の揺れや矛盾の検出
- ユースケースの抜けの発見
- ドメイン理解の加速
AIを対話と共通理解を深めるために最大限活用することが重要だと考えます。
終わりに
本記事では、ドメイン駆動設計（DDD）を実践する中で直面しやすい「迷い」について構造的な難しさとして整理してきました。
DDDは、一度正解を見つけて終わる設計手法ではありません。
- 仮の理解を置き
- 実装してみて
- 違和感に気づき
- 言葉とモデルを更新する
このサイクルを回し続けること自体が、DDDの実践だと感じています。
重要なのは、モデリングや設計をやり直せる前提を開発プロセスに落とし込み、続けられる形に落とすこと だと思います。
私自身、これからも学び続けていきたいと考えています。
ちなみに、明日でアドベントカレンダーも最終日ですね🎄✨
ラストは同じチームの @komugi8 さんが担当なので、楽しみにしています🙌
