コンテンツにスキップ
Process Compass（プロセスコンパス）

ドメイン駆動設計(DDD)

既存プロセスの体系 ／ 種別: 設計手法(設計の進め方・考え方)

ソフトウェアの中心に「業務領域の理解を写し取ったドメインモデル」を据え、ドメインエキスパートと開発者が共有する言語(ユビキタス言語)を通じてコードとして継続的に育てていく設計アプローチ

ひとことで言うと: 業務の言葉と仕組みをそのままコードの構造に写す設計の考え方。「いつ作るか」ではなく「何をどう設計するか」を扱い、スクラム等のリズムの内側で使う

全体マップ(第1階層)

各フェーズをクリックすると、フェーズ内のワークフロー(第2階層)へ移動します。

graph LR
  ph0["戦略的設計(Strategic Design)"]
  ph1["戦術的設計(Tactical Design)"]
  ph0 -->|"ユビキタス言語の一貫性検査 / 境界(コンテキスト)の妥当性検査"| ph1
  ph2["継続的リファクタリング(モデルの育成)"]
  ph1 -->|"モデルの業務妥当性検査"| ph2
  click ph0 "/process-compass/processes/ddd/strategic/" "戦略的設計(Strategic Design)の詳細へ"
  click ph1 "/process-compass/processes/ddd/tactical/" "戦術的設計(Tactical Design)の詳細へ"
  click ph2 "/process-compass/processes/ddd/continuous-refactoring/" "継続的リファクタリング(モデルの育成)の詳細へ"

目的と成果

目的(purpose): 複雑なドメインの本質的複雑性に開発の焦点を当て、業務の理解をソフトウェア構造へ忠実に反映し、変更に強いソフトウェアを作る

成果(outcomes):

  • ドメインエキスパートと開発者が同じ用語(ユビキタス言語)で会話し、その用語がコードのクラス名・メソッド名に一致する
  • 境界づけられたコンテキストとその関係を表すコンテキストマップが描かれる
  • 業務ルールがドメインモデル(エンティティ・値オブジェクト・集約)としてコードに凝集する
  • モデルが継続的リファクタリングで業務理解の深化に追随して育つ

原典: Eric Evans。原典『Domain-Driven Design』(2003、邦訳『エリック・エヴァンスのドメイン駆動設計』)。近年マイクロサービス・イベントストーミングと結びつき再興(DDDルネサンス)

ISO/IEC/IEEE 12207 対応: 主に「テクニカル(アーキテクチャ定義・設計定義、および上流のステークホルダー要求定義を厚くカバー)」プロセス群をカバー

ロール

ロール責任日本の現場での実態
ドメインエキスパート(Domain Expert)業務知識の源泉。用語・ルール・プロセスを提供し、モデルの妥当性(業務として正しいか)を判定する。ユビキタス言語の共同オーナー業務部門・企画・PdM が兼ねる。多忙で設計会議に継続参加できず「巻き込み不足」が最大の失敗要因になりやすい
開発者/ソフトウェアスペシャリストドメインエキスパートの知識をモデル化しコードへ写す。モデルとコードの一致(モデル駆動設計)に責任を持つアーキテクト/テックリードが戦略的設計を、実装担当が戦術的設計を分担する非公式分業になりがち
ファシリテーター(イベントストーミング等)部門・専門の壁を越えた協働ワークショップを進行し、境界づけられたコンテキストと集約の発見を促す外部コンサル/DDD経験者が務めることが多い。社内に経験者がいないと成立しにくい

ゲート(決裁・レビュー)

ゲート種別Deliverables判定基準判定者判定結果
ユビキタス言語の一貫性検査検査と適応用語集 / 会話 / コード同一語が同一意味で使われているか / コードの命名と業務用語が一致しているかドメインエキスパート+開発者一致 / 用語の追加・改訂
モデルの業務妥当性検査検査と適応ドメインモデル / イベントストーミング成果物業務ルール・シナリオを正しく表現できるか(ドメインエキスパートが「その通り」と言えるか)ドメインエキスパート妥当 / モデル修正
境界(コンテキスト)の妥当性検査 ※DDD を WF の DR ゲートに組み込むとモデルが「一度承認したら凍結」され、継続的リファクタリングの前提が崩れる検査と適応コンテキストマップ各コンテキストでモデルが一貫しているか / 統合関係が過度な結合を生まないか開発者(アーキテクト)妥当 / 境界の引き直し

成果物(information items)

成果物作成者説明
ユビキタス言語(用語集/グロッサリ)ドメインエキスパート(Domain Expert)全会話・ドキュメント・コードで共有。コードの命名へ直結する
コンテキストマップ開発者/ソフトウェアスペシャリストコンテキスト間の統合方式・チーム間関係の合意。マイクロサービス境界設計へ引き渡す
ドメインモデル(図+コード)開発者/ソフトウェアスペシャリスト戦術設計の実装対象。エンティティ・値オブジェクト・集約として具現化する
イベントストーミングの成果物ファシリテーター(イベントストーミング等)ドメインイベント列・コマンド・集約・境界の付箋の壁。境界づけられたコンテキストと集約の発見材料

アンチパターン(建前 vs 実態)

戦術的パターンだけ真似る

建前(あるべき姿)戦略的設計(境界づけられたコンテキスト・ユビキタス言語)を土台に戦術設計を行う
実態戦略設計を飛ばし、エンティティ/リポジトリ等のクラス構成だけ模倣して「DDDをやった」とする
なぜ起きるか戦術パターンはコードで真似しやすいが、戦略設計は業務理解と協働を要し難しいため
弊害業務と乖離したモデルになり、DDD の本来の効果(変更への強さ)が得られない

ドメインエキスパート不在のモデリング

建前(あるべき姿)ドメインエキスパートと開発者の継続的協働でモデルの妥当性を守る
実態開発者だけが想像でモデルを作り、ユビキタス言語が育たない
なぜ起きるか受託構造で業務部門(発注側)と開発者(受注側)が組織的に分断され、継続的協働が契約の壁で成立しにくい
弊害モデルが業務を正しく写さず、DDD 導入が形骸化する

建前と実運用(日本の現場)

  • DDD は「当事者(業務+開発)の協働で妥当性を守る」ため、業務知識を持たない QA 部門の形式レビューはモデルの妥当性を判定できない
  • 受託開発ではドメインエキスパートと開発者が組織的に分断され、DDD の前提「継続的協働」が成立しにくい(日本での導入最大の障害の一つ)
  • 増田亨氏らの実践で日本語の学習環境は充実したが、「難しくて挫折した」層向けの入門書が出るほど学習コストの高さが共通課題

フェーズ一覧(第2階層へ)

参考文献