DDD 01 考え方(ドメイン・モデル・ユビキタス言語)

更新日:

入口 → DDD / 次 → DDD_02_戦略的設計(境界づけられたコンテキスト・サブドメイン・コンテキストマップ)

1. DDD が解決したい問題

ソフトウェアが難しくなる原因は、多くの場合技術ではなく業務の複雑さ。

よくある崩れ方:

  • 業務ルールが 画面・API・SQL・バッチにバラバラに書かれ、同じ判定が5か所にある
  • 「会員」「ユーザー」「顧客」「アカウント」が同じものか違うものか誰も説明できない
  • 業務の人と話すときは「仮押さえ」、コードでは status = 2。翻訳ミスでバグる
  • 何でも入った巨大な User クラス / utils.ts ができ、どこを直すと何が壊れるか分からない

DDD の答え:

  1. 業務を深く理解し、その理解(モデル)をそのままコードにする
  2. 言葉を揃える(ユビキタス言語)
  3. 意味の境界でシステムを分ける(境界づけられたコンテキスト → 02章)
  4. 業務ルールを1か所(ドメイン層)に集める(03〜05章)

2. ドメインとモデル

  • ドメイン: ソフトウェアで解決したい業務の領域。「EC サイトの受注」「美容院の予約」
  • モデル: ドメインのうち、解きたい問題に必要な部分だけを抜き出して整理したもの
    • 地図と同じ。路線図は正確な距離を捨てて「乗り換え」を分かりやすくしている
    • 「現実を完全に写す」のではなく「目的に役立つように単純化」するのがよいモデル
  • ドメインモデル: そのモデルを表したもの。図や文章でもよいが、DDD では最終的にコードがモデルそのものになるのが理想
業務の人の頭の中の知識
      │ 対話・例を出して確認
      ▼
モデル(言葉・ルール・関係)  ← 図やメモで共有
      │ そのまま実装
      ▼
コード(Order.confirm() / Money / ReservationPolicy …)
      │ 実装して分かった矛盾・新発見
      └──→ モデルを直す(行ったり来たり)

3. ユビキタス言語(Ubiquitous Language)

チーム全員が、会話・仕様書・画面・コード・テスト名のすべてで使う共通の言葉。DDD で一番効果が大きく、一番簡単に始められる。

✗ バラバラ○ ユビキタス言語
業務「仮押さえ」/ 仕様書「一時予約」/ コード status=2全部「仮予約」Reservation.status = 'tentative'、reservation.holdTentatively()
業務「お客さん」/ コード User, Member, Customer が混在「会員」=ログインできる人 Member、「購入者」=注文した人 Purchaser と定義して使い分ける
updateStatus(order, 3)order.ship()(業務の人が読んでも分かる)

進め方:

  • 用語集(グロッサリー)を作る:用語・意味・英語名(コード上の名前)・例・似ているが違う言葉
  • 会話で言葉がぶれたら、その場で「それは〇〇のことですか?」と確認し用語集を更新
  • コードの名前を業務の言葉に合わせる。業務で使わない技術用語(Manager, Data, Info, Helper)を避ける
  • 言葉が変わったらコードもリネームする(言葉とコードがずれると価値が消える)

用語集の例

用語コード名意味注意
仮予約TentativeReservation / status: 'tentative'支払い前に24時間だけ枠を押さえた状態24時間で自動キャンセル
本予約status: 'confirmed'支払い済みの予約キャンセル料が発生しうる
会員Memberログインアカウントを持つ人「顧客」とは別(電話予約の非会員も顧客)

4. 知識の噛み砕き(Knowledge Crunching)

業務の人と開発者が一緒にモデルを作り込む活動。

  • 具体例で話す:「キャンセルはいつまで無料ですか?」「前日23:59に取り消したら?」「日付をまたぐ夜の予約は?」
  • 境界条件・例外を掘る:ルールの「ただし〜」にこそ業務知識が詰まっている
  • イベントストーミング:業務で起きる出来事(「予約が確定した」「入金が確認された」)を付箋で時系列に並べ、きっかけ(コマンド)・関わる人・ルールを書き足していくワークショップ。全体像と言葉のズレが一気に見える
  • ドメインエキスパートが分からない部分も明らかにする:「決まっていない」ことが分かるのも成果

5. モデル駆動設計 ― 分析と実装を分けない

  • 昔ながらの進め方:分析者がモデル図を描く → 別の人が実装 → 図とコードが乖離
  • DDD:モデルを作る人とコードを書く人を分けない。実装で見つかった矛盾をモデルに戻す
  • だから「ドメイン層のコードを読めば業務ルールが分かる」状態を目指す

6. 初学者向けまとめ

  • DDD の核心は部品(パターン)ではなく、業務理解と共通言語
  • 小さなアプリでも今日からできるのは:
    • 用語集を作り、コード・画面・会話で同じ言葉を使う
    • status = 2 のような意味の見えない値を、業務の言葉の名前にする
    • 業務ルール(「〜のときは〜できない」)を1か所にまとめる
  • 部品やアーキテクチャは「ルールが複雑になってきたら」取り入れればよい(DDD_06_実務の注意(やりすぎ・TypeScript・AI開発))
このノートを参照しているノート