TL;DR
- 設計に登場するものは、ドメインエキスパートのメンタルモデルにあるものと同じでなければならない。逆に、ドメインエキスパートのモデルにないものを設計に含めるべきではない。
- そのために、チーム全員が共有するユビキタス言語を作る。ユビキタス言語はコンテキストごとに異なる。
内容
設計とメンタルモデルを一致させる
設計に存在するものは、ドメインエキスパートのメンタルモデルにあるものと同じでなければならない。たとえば、ドメインエキスパートが何かを「注文」と呼んでいるなら、コードにも Order というものを用意し、同じように振る舞わせるべきである。ただし、「注文」の定義は発送部門と請求部門とで異なる。
逆に、ドメインエキスパートのモデルにないものを設計に含めるべきではない。たとえば OrderFactory、OrderManager、OrderHelper である。コードベースの中にこうした技術的な用語が出てくることはあるが、設計の一部として公開するのは避けるべきである。
ユビキタス言語
ユビキタス言語は、チーム全員が共有する概念と語彙の集まりであり、ビジネスドメインについての共有のメンタルモデルを定義する言語である。
- 名前のとおり、要件、設計、コードのあらゆる場所で使う
- ドメインエキスパートが一方的に決めるのではなく、チーム全員が協力して作る
- 固定されたものではなく、絶えず更新される
また、すべてのドメインやコンテキストをカバーするユビキタス言語は作れないことを知っておく必要がある。それぞれのコンテキストにはユビキタス言語の「方言」があり、同じ言葉でも意味が異なる。たとえば「クラス」は、CSS とオブジェクト指向プログラミングとで意味が違う。無理に同じ意味にそろえると要件が複雑になり、重大な設計ミスにつながるおそれがある。
キーワード
自分の理解
日本語で仕事をしていると、ドメインエキスパートの言葉からコードの英語へ、もう 1 段階の変換が挟まるのがネックである。ドメインに日本語を使うという手もある（参考: 日本語プログラミングで Go ドメイン駆動設計に入門してみた）。