ユビキタス言語
DDD (Domain-Driven Design) における「ユビキタス言語 (Ubiquitous Language)」は、なぜ glossary や terminology や vocabulary ではなく "language" と呼ばれるのか。ここでの答えは、ユビキタス言語の設計とはドメインモデリングそのものだから、というものである。言語を設計するとは、語彙だけでなく、データの構造と振る舞いを文法として決めることを指す。
ユビキタス言語の定義
A language structured around the domain model and used by all team members within a bounded context to connect all the activities of the team with the software.
同資料 Ubiquitous Language パターン (p.4) の "Therefore" 節は次の指示を出す。
Use the model as the backbone of a language. Commit the team to exercising that language relentlessly in all communication within the team and in the code. Within a bounded context, use the same language in diagrams, writing, and especially speech.
これらは一致して "language" という語を使う。ただし「言語」と呼ぶ内実 (用語集と何が違うのか) を正面から整理したものは少ない。多くの資料は実践の指示 (使い続けよ、話せ、コードに落とせ) に重きを置き、語の並びと言語を隔てるものが何かには踏み込まない。
名詞だけでは言語にならない
言語学の側から見ると、語彙の集まりだけでは言語にならない。
Saussure 『一般言語学講義』(原著 1916 年刊、Baskin 英訳 1959) は、言語を記号の体系 (système) として捉えた。個々の記号は他の記号との差異によって意味を持つ。語彙を並べただけでは体系にならず、記号の組み合わせ方を規定する文法が要る。 Wittgenstein 『哲学探究』(1953) §43 は「大部分の場合、語の意味とは言語における使用である」と述べる。 For a large class of cases—though not for all—in which we employ the word 'meaning' it can be defined thus: the meaning of a word is its use in the language.
辞書の定義ではなく、話者が実際にどう使うかが意味を定める、という主張である。
Saussure が体系性を、Wittgenstein が使用を指摘していることをあわせると、言語には語の組み合わせを規定する文法と、語が実際に使われる場の両方が要る。用語集は名詞 (とせいぜい短い定義) の並びであり、ある業務の概念と別の概念がどう関係するか、業務の上でどんな振る舞いが起こるか、どの状態からどの状態に移れるかを記述する文法を持たない。文法がなければ文は作れず、文がなければ使用が成り立たない。DDD が "language" と呼ぶ対象は、語彙と文法、そしてその使用の場をあわせたものである。
ユビキタス言語の設計はドメインモデリングそのもの
ユビキタス言語の設計とドメインモデリングは同じ作業である。言語を設計するとはどういうことかを分解すると、それぞれがドメインモデルの何を決めることに相当するかが一対一で対応する。
言語学では言語の中身を lexicon (語彙)、syntax (統語)、semantics (意味)、pragmatics (語用) の四つに分けて論じるのが標準的である。形態論 (morphology) もあるが、ドメインモデリングで中心的な論点にはならないので省く。ユビキタス言語を考えるうえでも、この四つで主要な要素を取り出せる。
lexicon (語彙) — どういう語があるか。ドメインの名詞 (注文、顧客) と動詞 (注文を検証する、注文を承認する) の集まり
syntax (統語) — 語をどう組み合わせるか。「注文は注文番号と顧客と配送先住所から成る」のような複合の規則、「注文数量は個数かキログラムのいずれか」のような分岐の規則
semantics (意味) — 語や文が何を指すか。注文という語は業務上どういう状態のもので、どの属性を持ち、どのような制約を満たしているか
pragmatics (語用) — 文脈によって語の意味がどう変わるか。同じ「顧客」が販売文脈と請求文脈で異なる意味で使われる、など
この四要素をドメインモデルの要素と対応させると以下のようになる。
table:table
言語の要素 ドメインモデルでの対応
lexicon 概念と操作の名前
syntax 概念の構成 (複合、分岐、任意)
semantics 不変条件、事前/事後条件、状態遷移
pragmatics Bounded Context による文脈の切り分け
例えばドメイン記述ミニ言語で書けば、lexicon は data 名・behavior 名に、syntax は AND・OR・? に、semantics は behavior の入出力仕様 (->) とその前後に成り立つ条件に、pragmatics は bounded context ごとに異なる data 定義にそれぞれ対応する。 この対応の中で、用語集と言語の分かれ目になるのは semantics の層である。lexicon で「注文」や「未検証注文」という語を並べ、syntax でそれらを複合規則や分岐規則で組み立てるところまでは、名詞の構造化に留まる。behavior 注文を検証する = 未検証注文 -> 検証済み注文 OR 検証エラー と書いてはじめて、「未検証注文」という語が「検証すると検証済み注文か検証エラーのどちらかになる」という使われ方を伴って定義される。ここが用語集には書き込めない層であり、ユビキタス言語をユビキタス言語たらしめる層でもある。
前節で Wittgenstein の「語の意味は使用によって決まる」を引いた。behavior は、業務の上で語が実際にどう使われるかを記述する。語を使うとは、その語を入力や出力に取る操作を書き、その操作の前後でどういう状態が約束されるかを書くことである。behavior なしの用語集は、語の並びはあっても、その語がどう使われてよい/使われてはいけないかを書けない。辞書に「注文」と書いてあっても、未検証のまま出荷できるのかできないのかは辞書を見ても分からない。behavior は「注文を出荷するには検証済みでなければならない」という使用規則を明示する。
pragmatics の層は Bounded Context に対応する。同じ「顧客」という語が販売の文脈と請求の文脈で指すものが違うとき、二つの異なる bounded context に別々の data 定義を置くのは、語用論的な分離を構造として書いていることになる。Evans 2015 p.vi が context を "The setting in which a word or statement appears that determines its meaning" と定義するのは、ここを指している。
以上のように四層それぞれが data と behavior と AND/OR/?/-> と Bounded Context に対応する以上、ユビキタス言語を設計することと、ドメインモデルの語彙・構成・意味・文脈を決めることは同じ作業である。Evans が "Use the model as the backbone of a language" (DDD Ref p.4) と述べ "a change in the language is a change to the model" (同 p.4) と続ける理由もここにある。モデルが言語の骨格であり、言語の変更がモデルの変更である以上、言語設計はモデリングそのものである。
用語集との違いもこの対応から説明できる。ここでは、用語集を lexicon だけを書いて syntax と semantics と pragmatics を暗黙に残した成果物として整理する。この整理でいえば、四層のうち一層しか書かないものが用語集であり、四層すべてを書くものがユビキタス言語である。両者の差は扱う層の多寡にある。具体的に四層すべてを書ける記法の例として、ドメイン記述ミニ言語 (Wlaschin 2017 『Domain Modeling Made Functional』を元にした記法) を参照されたい。同ページには「フラグではなく OR で状態を表す」「ステータスコードではなく状態と遷移を OR と behavior で明示する」「ほぼ同じ data が複数あるときは差分の理由 (必須項目・不変条件・段階/責務) で表現を切り替える」といった指針がまとめられている。これらはすべて、syntax と semantics をどう組み立てるかを決めると同時に、ドメインモデルの不変条件・状態機械・概念の切り方を決める判断である。 同じ方向の先行論
ここでの立場 (ユビキタス言語は名詞の集まりではなく文法を含む半形式の言語であり、その設計はドメインモデリングそのものである) と同じ方向で論じている先行論は、DDD コミュニティの周辺に複数ある。
Dan North と BDD (Behaviour-Driven Development)。North は 2003 年以降 BDD を提唱し、2007 年には Gherkin という Given-When-Then 構文の DSL を導入した。Wikipedia の BDD 項目は BDD とユビキタス言語の関係を次のように整理している。 A ubiquitous language is a (semi-)formal language that is shared by all members of a software development team — both software developers and non-technical personnel. ... some formality is a requirement for being a ubiquitous language. Having such a ubiquitous language creates a domain model of specifications, so that specifications may be reasoned about formally.
「ユビキタス言語であるためには何らかの形式性が要る」「ユビキタス言語を持つことは仕様のドメインモデルを作ることである」という主張は、ここでの「言語の設計はドメインモデリングそのもの」と重なる。BDD は振る舞いの記述 (Given-When-Then) を semi-formal な構文で書く点で、ドメイン記述ミニ言語の behavior ... = ... -> ... と目的を共有している。
Scott Wlaschin『Domain Modeling Made Functional』(2018)。Wlaschin は F# の代数的データ型 (直和型・直積型) でドメインを記述する方法を示し、types がそのままユビキタス言語の記述になるとした。参照したドメイン記述ミニ言語の data・behavior・AND・OR・-> は Wlaschin のアプローチから派生している。types による記述は名詞 (data) と動詞 (behavior) の両方を扱い、コードがそのままドキュメントになる点で、ユビキタス言語を半形式言語として扱う立場に立つ。 Cyrille Martraire『Living Documentation』(2019)。Martraire はユビキタス言語が既にコード (クラス・インタフェース・メソッド) に埋め込まれているとし、アノテーションとスキャナによってコードから常に最新の glossary を生成する仕組みを示す。振る舞いについては BDD シナリオ (Cucumber) を live な specification として扱う。文書としての glossary が陳腐化する問題への応答であり、ユビキタス言語の保存場所をコードに求める点でここと立場が近い。 Vlad Khononov と Derek Comartin。この二者は、DDD の core は tactical pattern (Entity, Value Object, Aggregate 等) ではなくユビキタス言語であり、pattern 中心の DDD 理解は誤りであるという立場を明示している。Khononov はブログ記事「Tackling Complexity in the Heart of DDD」(2016) で次のように書く。 Eric Evans himself stated that the Domain Model implementation described in the Blue Book was intended to be a way of implementing a Domain Model, but many mistook it as the way of implementing Domain-Driven Design.
Domain design is not about design patterns. But a lot of people think it is. They think they have a checklist of patterns, entities, aggregates, value objects, repositories... Domain. Driven. Design. Not pattern driven design. It's in the title.
代わりに Comartin が推奨するのは次の順序である。
Start by talking to people within the domain. Model workflows. Use the business's language. Then reach for things like entities and value objects.
両者の主張は、ここでの「言語の設計こそがドメインモデリングそのもの」と同じ方向を向いている。ただし UL をどう書くかの具体形式 (半形式の記法) までは示されていない。
これらの先行論に共通するのは、ユビキタス言語を「用語の一覧」ではなく「振る舞いを含む半形式の記述」として扱い、その記述がドメインモデルと同じ対象を指すと見る視点である。ここでの立場も同じ系譜にある。ただし先行論の多くは、Evans の元々の定義の曖昧さそのものを正面から問題化していない。BDD は Evans の UL を所与として BDD ツールとの接続を論じ、Wlaschin と Martraire はそれぞれ F# とコード中心の Living Documentation という具体手法を提示し、Khononov と Comartin は DDD の core が UL にあることを強調するが、UL をどう書くかの具体形式までは示さない。ここでは、Evans 自身が "handwavy good advice" と認めた曖昧さを出発点に置き、なぜ用語集化が世界中で起きたかを説明したうえで、ドメイン記述ミニ言語のような文法を持つ記述が、Evans が明示しなかった syntax・semantics・pragmatics の三層を具体的に書けることを示した。
概念が曖昧なまま流通してきたこと
ユビキタス言語は DDD の中心概念でありながら、その定義は Evans 2003 以来、概念としての輪郭がはっきりしないまま流通してきた。Evans 自身がその曖昧さを認めている。
On one end of the spectrum lies "handwavy good advice" that is really just "feel good mush." The other extreme is a trivial "cookbook" that must be rigidly followed.
"handwavy good advice" "feel good mush" は、それまで流通していた DDD の言い回し (まさにユビキタス言語の説明を含む) に対する自己批評である。2019 年 DDD Europe の "Language in Context" では、Bounded Context を含む fundamental terms がしばしば誤解されていると認め、コミュニティに語彙の改善を呼びかけた (Thomas Betts, InfoQ 2019-09-20)。 Evans のこれらの自己批評は、ユビキタス言語を含む DDD の中核概念が、「これは何か」「これをどう書くか」について厳密な規定を欠いたまま流通してきた事実と整合する。Evans 2015 DDD Reference の Ubiquitous Language 節が Lewis Carroll の詩から始まり、"exercise relentlessly"、"especially speech"、"play with the model" という行動の呼びかけで組み立てられていることは、この節が概念の定義ではなく実践の指示を主眼に置いていることを示している。
ここでの提案はこの文脈に置かれる。ユビキタス言語とは何か、について Evans 自身が厳密な定義を与えなかった部分を、「言語の設計 = ドメインモデリング」と読み直し、その設計がドメイン記述ミニ言語のような文法を持つ記述として具体化できることを示す。Evans を置き換える主張ではなく、Evans 自身が "handwavy good advice" と呼んだ記述を、文法を持つ具体的な記述に置き換える提案である。
流通している成果物は実際には用語集になっている
前節の主張 (概念が曖昧なまま流通してきた) は、公開されているユビキタス言語の成果物を観察すると裏付けられる。以下は確認できた公開事例である。
IFRC CBS (赤十字・赤新月社 Community Based Surveillance) (Glossary: Ubiquitous language)。OSS として GitHub wiki 上で公開されている。構成は「RCRC」「CBS Project」「Roles」「Health Risk」「Case Report」の 5 カテゴリで、各項目は定義文・Rule・代替用語・参照情報からなる。内容は名詞 (組織、役割、疾病、報告形式) の定義が中心で、振る舞いや状態遷移の記述は限定的である。 LegalOn Technologies「新規機能開発におけるユビキタス言語のパワー」。Notion データベースで Feature Flag、Managing Flags、Toggle などの用語を日英併記で定義し、仕様書にリンクする運用。記事は名詞中心で、動詞や状態遷移の具体的な扱い方は示されていない。 Progate「ユビキタス言語策定活動の紹介」。成果物はスプレッドシートによる「ユビキタス辞書」(ステータス・英名・和名・意味・参照) と Figma のドメインモデル図 (オブジェクト名・プロパティ・関係) の二つ。記事の記述は概念 (名詞) の整理が中心で、振る舞いや状態遷移の扱いには及んでいない。 Matt Pocock の ubiquitous-language skill。会話から glossary を抽出して UBIQUITOUS_LANGUAGE.md に記録する AI 補助ツール。"nouns, verbs, and concepts" を対象とすると説明にあるが、出力例は名詞の表と概念間のカーディナリティ (An Invoice belongs to exactly one Customer) が中心で、振る舞いや状態遷移の扱いは明示されていない。 Qiita の mishiwata「ユビキタス言語のフォーマットサンプルを探してみた」は、日本語圏で見つかった 6 事例を比較している。著者自身が「具体例があまり見つかりませんでした」と書いているうえ、6 事例のうち動詞 (アクション) を扱うのは 1 件のみで、残りは「単語・英語・概要」を並べる名詞中心のフォーマットである。 公開されている成果物を横断して見ると、ほとんどがスプレッドシートや Notion、GitHub wiki 上の用語リストであり、名詞 (Entity・Value Object に相当する概念) の定義が中心である。振る舞いや状態遷移、不変条件を同じ成果物の中で体系的に扱うものは見当たらない。前節で述べたように、Evans がユビキタス言語に関して「こう書け」と指示していないので、各チームは自前で形式を発明することになり、結果として、もっとも作りやすい「名詞の辞書」を採用することになる。これは概念が曖昧なまま流通したことの実証的な帰結である。
日本語訳「同じ言葉」が落とすもの
Khononov 2021 Learning Domain-Driven Design の邦訳『ドメイン駆動設計をはじめよう』(増田亨・綿引琢磨訳, 2024) では、ユビキタス言語が「同じ言葉」と訳されている。原語のカタカナを外して日本語として意味を通す方針で、同書は domain を「事業活動」、subdomain を「業務領域」、bounded context を「区切られた文脈」とも訳している。 四層の分解から見ると、「同じ言葉」は lexicon の層にしか対応しない訳語である。「同じ」は一意性の要求を、「言葉」は語彙の並びを指す。これで落ちるのは syntax・semantics・pragmatics の三層である。syntax (語の組み合わせ規則) と semantics (behavior が担う使用規則) に相当する語は訳語に含まれない。
原語 "ubiquitous language" がカタカナのままであれば「語ではなく言語」という違和感が読者側に残るが、「同じ言葉」だとその違和感もない。結果として、日本語圏では lexicon だけを揃えることがユビキタス言語の実践だと読まれやすくなる。公開されている成果物がすでに名詞中心に偏っている現状で、訳語そのものがこの偏りを強める。
DSL との関係
Evans の論じる DSL は、オブジェクト指向言語の代わりにドメインを記述する実行可能な言語である。コンパイラやインタプリタで処理され、最終的にソフトウェアの実装になる。Evans 2015 p.36 の Published Language も、bounded context 間の交換のために形式化された機械可読な言語として位置する。
ドメイン記述ミニ言語はこれらとは別の位置にある。記法には文法があるが、コンパイラで実行される必要はない。同ページのシステムプロンプト例では「必ずしもその通りの型を作らなくても良い」「振る舞いで使われないデータは実装段階では型定義する必要はない」と明示されており、実装との対応は厳密でなくてよい。コレクションを示す List も「配列などの実装構造を指定するものではなく、複数あるという業務上の意味を表すための記号」と説明される。
つまりミニ言語は、人間とドメイン専門家と AI Agent が共有するための半形式的な記述言語である。ユビキタス言語に文法骨格を与える道具であり、実行可能な DSL はその文法の一部を機械に渡す際の固定化である。どちらもユビキタス言語を半形式以上の形で書き下す試みであり、どこまで形式化するかは設計対象と運用体制で決まる。
用語集として扱うとは文法なき言語として扱うこと
ユビキタス言語を用語集として運用することは、語彙だけを残し文法を捨てることである。その結果として起きる失敗モードを、Evans や Vernon の指摘を引きながら挙げる。
翻訳の蓄積。Evans 2015 p.3 は "Translation blunts communication and makes knowledge crunching anemic." と述べる。用語集は語の対応表に過ぎないので、ドメイン専門家と開発者の語りの差を個々の場面で翻訳し続けることになる。文を組み立てる文法が共通していないので、翻訳は語単位を超えて文単位で必要になる。
瞬間的表現の喪失。同 p.3 は "the most incisive expressions of the domain often emerge in a transient form that is never captured in the code or even in writing." とする。ドメイン理解の核心は発話の場で瞬間的に現れることが多い。用語集は静的な定義の保存場所であり、文を作って使う場を持たないので、この瞬間的な表現は記録されずに失われる。
ありえない状態の許容。フラグとオプショナル (?) の組み合わせだけで状態を表すと、業務上ありえない組み合わせまで構造が許してしまう。前節の「フラグではなく OR」と「ステータスコードではなく状態と遷移」の指針が効かないので、ドメインの不変条件が型の段階で守られない。
コードとの乖離。[Vernon 2013 Implementing Domain-Driven Design https://vaughnvernon.com/#iddd-book] は "the code is the enduring expression of Ubiquitous Language; be prepared to abandon drawings, glossaries and other documentation that will be difficult to keep up to date" と述べる。用語集としての文書は、言語としてコードと並行して使われない以上、時間経過とともにコードと食い違っていく。 まとめ
ユビキタス言語が "language" と呼ばれる理由は、その設計がドメインモデリングそのものだからである
名詞だけでは言語にならない。語彙に加えて、組み合わせを規定する文法と、使用の場が要る
ユビキタス言語を半形式の記述言語として扱う先行論 (BDD の Dan North、Wlaschin『Domain Modeling Made Functional』、Martraire『Living Documentation』、Khononov のブログおよび『Learning DDD』、CodeOpinion の Derek Comartin) は世界中に既に存在する。ここでは同じ系譜に属しつつ、Evans の定義自体の曖昧さを出発点にする点を独自の切り口とした
Evans 自身が 2018 年の講演で DDD の中核概念が "handwavy good advice" "feel good mush" に近い曖昧さを抱えていることを認めている。ユビキタス言語の定義が未規定のまま流通してきたことが、世界中の形骸化・精神論化の根本原因である
公開されているユビキタス言語の成果物 (IFRC CBS, LegalOn, Progate, Matt Pocock skill など) を横断しても、ほとんどが名詞中心の用語集であり、振る舞いや状態遷移を体系的に扱うものは見当たらない
日本語訳『ドメイン駆動設計をはじめよう』(2024) の「同じ言葉」は分かりやすさと引き換えに、"language" が持つ文法と体系の含意を落とし、用語集理解をさらに助長する方向に働く
ドメイン記述ミニ言語のような半形式の記法は、未規定だった文法レベルを具体的に記述する方法を提供する。ミニ言語の設計指針はそのままドメインモデリングの指針と一致する
実行可能な DSL は、文法の一部を機械に渡す際の固定化であり、ユビキタス言語の設計そのものではない
用語集として扱うことは文法を捨てることであり、翻訳の蓄積・瞬間的表現の喪失・動詞の欠如・ありえない状態の許容・コードとの乖離という形で現れる