設計・開発手法を整える
中級DDDを整える。
＝ 業務の言葉とコードを一致させる設計の考え方を、図と用語表で
境界づけられたコンテキストとユビキタス言語——DDD（ドメイン駆動設計）の入口となる2つの考え方を、通販の「注文・在庫・配送・請求」という自作の一般例で図解します。同じ「商品」という言葉でもコンテキストが変われば意味が変わる様子をクリックで確認でき、下のユビキタス言語 用語表メーカーで自分のプロダクトの用語表をMarkdownとして作れます。送信ゼロ。
TLDR — 30秒で分かる
同じ「商品」という言葉が、注文・在庫・配送・請求のコンテキストで違う意味を持つ様子をクリックで確認。用語・意味・コンテキスト・NGな言い換えを行追加してMarkdownでコピーできるユビキタス言語 用語表メーカーつき。
主な機能
- 境界づけられたコンテキスト図解（通販の注文/在庫/配送/請求の自作例・クリックでハイライト）
- 同じ言葉がコンテキストごとに違う意味を持つことを可視化
- ユビキタス言語 用語表メーカー（Markdown表でワンクリックコピー・保存なし）
- 戦略的設計と戦術的設計の2階層を整理
- MSAとの関係は通説として中立に紹介
- 送信ゼロ・ブラウザ内完結
⚠️ 以下の解説は、提唱者エリック・エヴァンス（Eric Evans）の考え方を一般的にまとめたものです。特定の書籍・記事の図や文章をそのまま使ったものではなく、用語の区切り方・呼び方は参考にする書籍や現場により多少異なることがあります。
⚠️ 下の境界づけられたコンテキストの例（注文・在庫・配送・請求）はtotonoeが作った一般的な例です。実際のシステム構成やコンテキストの区切り方は、プロダクトごとに異なります。
DIAGRAM
境界づけられたコンテキスト図解 — 同じ「商品」でも意味が違う
通販システムを例に、「商品」という同じ言葉が、注文・在庫・配送・請求という4つのコンテキストでそれぞれ違う意味・違う情報を持つ様子を図にしました。枠をクリックすると、そのコンテキストでの意味が下に表示されます。
💡 枠はクリックのほか、Tabで選んでEnter/Spaceでも切り替えられます。
注文コンテキスト での「商品」
—
—
INPUT
ユビキタス言語 用語表メーカー
用語・意味・コンテキスト・NGな言い換え（誤解を招く別名）を行追加でどんどん作れます。最初から入っている3行は、上の図解と対応するサンプルです。書き換えて自分のプロダクトの用語表として使ってください。
用語・意味・コンテキスト・NGな言い換えのすべてが空の行は、Markdown出力から自動で除外されます。
RESULT — Markdown表
そのままドキュメント・Wiki・READMEに貼り付けられるMarkdown表形式です。コピーボタンで丸ごとコピーできます（送信ゼロ・保存なし）。
解説
DDDとは——業務の理解とコードを一致させる考え方。
DDD（ドメイン駆動設計・Domain-Driven Design）は、ソフトウェア技術者エリック・エヴァンス（Eric Evans）が2004年の著書で提唱したとされる設計の考え方です。業務（ドメイン）の理解とコードの構造をできるだけ一致させることを目指す、という点が中心にあるとされます。業務担当者と開発者が同じ言葉で会話し、その言葉がそのままコードのクラス名・メソッド名に現れる——という関係を理想として掲げています。
上の図解と用語表メーカーで扱った境界づけられたコンテキストとユビキタス言語は、この考え方を実践するための入口となる2つの道具です。
戦略的設計と戦術的設計——2つの階層
DDDの実践は、大きく2つの階層に整理されることが一般的です。戦略的設計は「システム全体をどう区切るか」という大きな視点、戦術的設計は「1つのコンテキストの内側で、コードをどう組み立てるか」という小さな視点です。どちらか一方だけでは成立せず、両方が組み合わさってDDD全体を形づくる、という整理です。
戦略的設計（このページで扱う範囲）
ある言葉やモデルが一貫した意味を持つ範囲。範囲の外に出ると、同じ言葉でも意味が変わりうる、という前提に立ちます。
開発者と業務担当者が同じ言葉を同じ意味で使う、共通の語彙。コードの命名もこの言葉に合わせるのが理想とされます。
複数の境界づけられたコンテキスト同士が、どう連携・依存しているかを俯瞰する見取り図。
戦術的設計（コンテキストの内側）
属性が変わっても「同一のもの」として区別され続ける、識別子を持つオブジェクト（例：注文そのもの）。
識別子を持たず、属性の値そのもので同一性が決まるオブジェクト（例：金額、住所）。
関連する複数のオブジェクトを1つのまとまりとして扱い、外部からの変更はまとまりの入口（集約ルート）を通す、という単位。
集約を保存・取得する窓口を抽象化し、保存先（データベース等）の詳細をドメインのコードから隠す仕組み。
特定のエンティティや値オブジェクトだけには属さない業務ロジックの置き場所。
業務上意味のある「何かが起きた」という事実を表すオブジェクト（例：注文が確定した）。
DDDとマイクロサービス（MSA）の関係
DDDの境界づけられたコンテキストは、マイクロサービスへ分割するときの単位の候補になりうる、とよく言われます。ただしDDDはサービスをどう物理的に分割するかを規定するものではなく、あくまで「意味の境界」を整理する考え方です。1つのコンテキストが必ず1つのサービスに対応するとは限らず、どこまで一致させるかは流派・現場により判断が分かれます。分割そのものを体感してみたい場合は「MSAを整える」もあわせてご覧ください。
使い方
「同じ言葉でも意味が違う」を疑うところから始める。
- 1
上の図で、同じ言葉が部署ごとに違う意味を持つ様子を確認する。
「商品」という一つの言葉が、注文・在庫・配送・請求のどこで使われるかによって、指すもの・持つ情報が変わることを4つの枠をクリックして確認してください。これが境界づけられたコンテキストの出発点です。
- 2
自分のプロダクトの言葉に置き換えて、用語表メーカーに入れてみる。
「この用語、営業とエンジニアで意味がズレていないか？」と思う言葉があれば、用語・意味・コンテキスト・NGな言い換えの4項目で書き出してみましょう。行はいくつでも追加できます。
- 3
できた用語表をMarkdownでコピーし、チームのドキュメントに貼る。
用語表はそのまま社内Wiki・README・設計ドキュメントに貼り付けられるMarkdown表として出力されます。合意した言葉を都度ここに足していけば、そのままユビキタス言語の台帳として育てられます。
⚠️ 本ページの解説はDDDの一般的な考え方の要約です。実際の設計判断（コンテキストの区切り方・戦術パターンの適用など）は、プロダクトの規模やチーム事情によって最適解が異なります。送信ゼロ（入力した用語表はこの端末から出ません・保存もされません）。
BDD・DDD・MSA・TDDは、同じプロダクト開発の中で場面ごとに同時に使われる考え方であり、どれか1つを選んで他を捨てるような関係ではありません。
🔒 図解の表示・用語表メーカーの入力・出力は、すべてこの端末（ブラウザ）の中で完結します。入力内容はサーバには送られず、保存もされません（送信ゼロ）。
よくある質問
Q. DDD（ドメイン駆動設計）とは何ですか？
A. 業務（ドメイン）の理解とコードの構造をできるだけ一致させることを目指す設計の考え方で、提唱者としてEric Evansの名前が知られています。業務担当者と開発者が同じ言葉で会話し、その言葉がそのままコードの命名に現れる関係を理想として掲げているとされます。
Q. 「境界づけられたコンテキスト」とは何ですか？
A. ある言葉やモデルが一貫した意味を持つ範囲のことです。例えば通販の「商品」は、注文コンテキストでは注文明細の1行、在庫コンテキストでは倉庫にある実体、と文脈で意味が変わります。この境界を意識せず1つの巨大なモデルにまとめようとすると、意味の衝突や無理な汎用化が起きやすい、とされます。
Q. 「ユビキタス言語」は普通の用語集と何が違いますか？
A. 開発者と業務担当者が同じ言葉を同じ意味で使う共通の語彙で、その言葉がコードのクラス名・メソッド名にもそのまま使われる点が用語集との違いです。ただし1つの言葉でもコンテキストが変われば意味は変わりうるため、「どのコンテキストでの言葉か」を明示することが重要とされます。
Q. DDDとマイクロサービス（MSA）はどんな関係にありますか？
A. DDDの境界づけられたコンテキストは、マイクロサービスへ分割するときの単位の候補になりうる、とよく言われます。ただしDDDはサービスの物理的な分割方法を規定するものではなく、1つのコンテキストが必ず1つのサービスに対応するとは限りません。どこまで一致させるかは流派・現場により判断が分かれます。
Q. 用語表メーカーで入れた内容は保存・送信されますか？
A. いいえ。入力・生成されるMarkdown表はすべてこの端末の中だけで処理され、サーバーには送信されません。保存も行っていないため、タブを閉じると内容は消えます。自社プロダクトの用語を入れても外部に出ることはありません。
入力値はURLの「#」以降に入るためサーバーには送信されません。リンクを開くと同じ状態を復元します。
RELATED TOOLS
続けて整える
