ddd-ubiquitous-language について
境界づけられたコンテキスト内で、ドメインエキスパートと開発者の語彙をそろえるスキルです。ドメイン用語をコードやテストに反映し、同義語や全社共通の用語統一を避ける方法を扱います。
主な機能
- 01共有ドメイン語彙の構築
- 02コードとテストへの用語反映
- 03境界づけられたコンテキスト内での言語統一
- 04同義語や命名のずれの検出
活用シーン
- 01新規プロジェクトでのドメインモデリング
- 02チーム間の用語のずれの解消
- 03ドメインエキスパートに沿ったコード命名
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/ddd-ubiquitous-languageを入力して読み込まれたか確認します。
詳細
1行での要約
1つの境界づけられたコンテキスト内で、ドメインエキスパート、開発者、コード、テストが共有する語彙を確立します。
このスキルを使う場面
- ドメインのモデル化を始める新しいプロジェクト。
- ビジネスとエンジニアリングの間で用語のずれが続いている。
- コードの名前がドメインエキスパートの話し方と一致していない。
- 会話とコードの間に翻訳表がある（「ビジネス側が『請求書』と言うとき、
BillingDocumentを指します」）。
このスキルを使わない場面
- コードレベルのパターンに関する質問 → 戦術的なパターンのスキルに委ねます。
- コンテキストをまたぐ用語の翻訳 →
ddd-context-mappingに回します。 - 変数や関数の一般的な命名規則 → これはコードスタイルの問題であり、DDDではありません。
中核となる内容
ユビキタス言語とは、ドメインエキスパートとエンジニアがモデルについて話し合うために使う、共有された正確な語彙です。そして、その語彙はコード、テスト、データベース、UIにそのまま現れます。チームが参照することに合意した用語集ではなく、実際に話し、書く言葉です。
育て方。 ドメインエキスパートの話に耳を傾け、言い換えずにその表現を記録します。エキスパートが「支払いを精算する」と言うなら、コードには processPayment ではなく、settle というメソッドを用意します。用語についてエキスパートの意見が食い違う場合は、意見をすり合わせてもらいます。その食い違いには、実際の違いが隠れています（多くの場合、2つの概念が1つの言葉に押し込められています）。
境界づけられたコンテキストごとに。 ユビキタス言語の一貫性が保たれるのは、1つの境界づけられたコンテキスト内です。2つのコンテキストで同じ言葉が異なる意味を持つこともありますが、それで問題ありません。翻訳はコンテキストマッピングで扱います。誤りなのは、企業全体で1つの言語を強制しようとすることです。
音読テスト。 コードの一部（メソッド本体、テスト名、クラス階層など）をドメインエキスパートに向けて音読します。その内容を理解してもらえれば、その言語は機能しています。「それはどういう意味ですか？」と尋ねられるなら、その言語はモデルからずれています。
判断のヒューリスティクス
- 1つの境界づけられたコンテキストの内部に適用します。企業全体で言語を統一したいという衝動には抗います。
- エキスパートに概念の呼び方を尋ねず、開発者が「Manager」「Helper」「Processor」のような名前を作る場合は、異議を唱えます。
- 同義語は徹底的になくします。1つのコンテキスト内で同じ意味を持つ「Customer」「Client」「Account」を共存させてはいけません。
アンチパターン
- エキスパートに尋ねるのは「時間がかかりすぎる」と、開発者が名前を作る。
- チームごとに好みの言葉が異なるため、同義語を許容する。
- 会話とコードの間に翻訳表を置く。これはモデルがずれている兆候です。
- コードそのものを用語集にせず、用語集を別の文書として維持する。
関連項目
ddd-bounded-context— コンテキストごとに1つの言語を使います。境界によって、一貫性のある言語が可能になります。ddd-design— 言語は、あらゆる設計セッションの最初の成果物です。ddd-context-mapping— コンテキスト間で言語を翻訳します。
参考文献
- Evans、『Domain-Driven Design』（2003年）、第2章（コミュニケーションと言語の利用）。