Skip to content
Published on

ドメイン知識はなぜ防衛線なのか — 業を知るエンジニアと技術だけのエンジニア

🇰🇷KO🇺🇸EN🇯🇵JA🇨🇳ZH
Split View필사 모드
シェア
Authors

同じ画面を見て違うものを読む人

構成した例です。注文キャンセル機能に条件が一つ付いています。出荷済みの状態ではキャンセルできず、返品に切り替わります。コードだけ知る人はこれを状態遷移の規則として読みます。業を知る人は、出荷の時点で倉庫へ作業指示がすでに出ており、その指示を戻すには倉庫の人が手で捕まえねばならず、捕まえられる時間が何分かによってこの規則の境界が決まったことを知っています。

二人の違いはこの機能を直すときにはあまり出ません。この機能を変えてよいかを判定するときに出ます。

ドメイン知識はなぜ防衛線なのか

第1回で、検証を高くする第一の要因として暗黙の文脈を挙げましたが、ドメイン知識がまさにそれです。コードに無く、文書にもたいてい無く、人の記憶と組織の慣行だけにあります。

第3回で引いたBrooksの区別に移せば、ドメイン規則は偶有的複雑性ではなく本質的複雑性です。利用者が三十のことを望むならその三十は問題自体から出たものなので取り除けない、というのが彼の例でした。道具を変えてもこちら側は減りません。

ただし防衛線という言葉が、他人を入れないための堀として読まれては困ります。ドメイン知識が価値を持つ理由は希少だからではなく、それ無しには判定が不可能だからです。だからこの知識は分け与えても減らず、むしろ分け与えられる形にする仕事がこの能力の半分です。

業を知るエンジニアが違えている三つ

一つめ、問いの種類が違います。技術だけの側はこのフィールドは何を意味するのかと尋ねます。業を知る側は、この値が空の注文が実際にあるのか、あるならどんな場合かと尋ねます。二つめの問いがデータの本当の形を引き出します。

二つめ、例外への姿勢が違います。要求に付いた妙な例外条項を見ると、技術だけの側は汚いと感じて整理したがります。業を知る側は、この条項がどんな事故の痕跡かを先に尋ねます。そうした条項はたいてい誰かが損をしたあとに生まれており、消せばその損が戻ってきます。

三つめ、何が本当の要求かを見分けます。第6回で要求は解決策の姿で届くと書きましたが、その翻訳を戻すにはドメインが要ります。知らなければ問い返しても返ってきた答えを理解できません。

言葉がずれるとコードがずれます

ドメインをコードへ移す地点で最もよく壊れるのは用語です。

Eric Evansがドメイン駆動設計で示したユビキタス言語がこの問題を扱います。Martin Fowlerの整理によれば、これは開発者と利用者のあいだに共通で厳密な言語を築く実践であり、その言語がドメインモデルに根ざすべき理由は、ソフトウェアが曖昧さをうまく扱えないからです。同じ文はEvansを引いて役割を分けます。ドメイン専門家はドメイン理解を伝えるのにぎこちない、あるいは足りない用語や構造に異議を唱えるべきであり、開発者は設計をつまずかせる曖昧さと不整合に目を配るべきだ、と。

うまくいっていない合図は単純です。会議で使う言葉とコードにある名前が違えば、その差の分だけ毎回翻訳が起き、翻訳は毎回誤訳の機会です。

例 — 用語の対照表

業務側の言葉   コードにある名前                 同じものか
精算           settlement, payout, clearing    要確認。三つに分かれた理由は
出荷           shipped                         同じ
返品           return, refund                  違う。物と金が別に動く

危ないのは一行目のような場所です。業務側が一語で呼ぶものがコードで三つに分かれていて、誰もその違いを文として持っていないなら、そこから静かに誤った値が出ます。

ドメインを身につける六段階

  1. 用語を集めます。 議事録、画面、顧客から来たメールに出る名詞を、判断せずに集めます。
  2. 同じ語と違う語を分けます。 別の語が同じものを指すなら統合し、同じ語を二部署が別に使うなら分離します。二つめが最も価値ある発見です。
  3. 物と出来事を分けます。 持続する対象か、ある時点に起きたことかを分けます。この区別がデータモデルの骨格です。
  4. 関係に数を付けます。 一対一か、一対多か、多対多か。ここで誤解が最も多く出ます。
  5. 検証の問いを作ります。 モデルが正しければ答えられるはずの問いを五つ、ドメイン専門家に尋ねます。答えが詰まればモデルが誤りです。
  6. 例外を狩ります。 この規則が当てはまらない場合はあるかと繰り返し尋ねます。例外が出てこないドメインは、まだ掘りが足りません。

最もよく飛ばされるのは五つめです。モデルを描くところまでは皆行き、そのモデルで答えられない問いを探すところまでは行きません。第4回の言い方では、モデルを描くのが生成で、検証の問いを作るのが判定の設計です。

ドメイン知識が通じない場所

正直に書くべき限界が三つあります。

一つめ、持ち越しが利きません。十年積んだ物流のドメインは、別の業へ移ればかなりの部分が捨てられます。だからドメインだけに投資するのは危うく、前の九回で扱った持ち越せる能力と一緒に進む必要があります。

二つめ、業そのものが縮む場合があります。深いほどこの危険は大きくなるので、ドメインを選ぶときにその業がどこへ向かうかは技術選択と同じくらい重要な問いです。

三つめ、過適合があります。一つの業に長くいると、その業の慣行を物理法則と取り違えやすい。もともとこうする、という言葉が自分の口から出たら点検の時です。理由を文にできないなら、それは理由ではなく習慣です。

シリーズを一文で

十回を一文に縮めるとこうなります。値が残る技術は検証費用が高い技術であり、エンジニアの仕事はその高い判定を安い判定に変える仕掛けを設計することです。デバッグ、読むこと、テスト、書くこと、問題定義、運用、委譲、学習、ドメインは、すべてこの一文の別の顔でした。

道具の一覧で答えなかった理由もここにあります。一覧は古び、判別式は古びにくい。次に新しい道具が出たとき問うべきことは二つです。これは何を安くするのか。その結果、何の判定が高いまま残るのか。

手を動かす

今週、自分のチームのドメイン用語を十個書き出し、業務側の人が使う言葉とコードにある名前を並べて書いてみてください。三十分で足ります。違う欄が一つでも出れば、そこが翻訳の起きる地点であり、そこから静かに誤った値が出ます。

  • FDEエンジニア育成RPG — ドメイン分析・オントロジー作成コースが上の六段階をそのまま訓練します。製造MES・物流・与信の三つの架空業界で、ステークホルダーのインタビューを読み、用語を正規化し、オブジェクトタイプ・プロパティ・リンクタイプをカーディナリティまで付けて組み立て、検証の問いでモデルを試します。
  • 協業RPG — ドメインは結局のところ人から来ます。尋ねるという選択と、先送りにした会話が、数週間後にどんな値で返ってくるかを時間差で見せます。

通じない場合も書いておきます。数週間の作業として入った場所でドメインを深く掘っても回収できません。そのときは第3回の結論と同じです。理解ではなく境界だけ掴めば足ります。

続けて読む

高いまま残る技術シリーズ

参考資料

  • Ubiquitous Language — Martin Fowler — 開発者と利用者のあいだに共通で厳密な言語を築く実践という定義、ソフトウェアが曖昧さをうまく扱えないという論拠、ドメイン専門家と開発者がそれぞれ何に目を配るべきかというEvansの引用がここから来ています。2026-08-15閲覧。
  • No Silver Bullet — Wikipedia要約 — 本質的複雑性は解くべき問題自体から生じるので何によっても取り除けないという整理と、利用者が三十のことを望むならその三十が本質だという例がここから来ています。2026-08-15閲覧。
  • 六段階の手順と用語の対照表は上記資料にあるものではなく、この記事でまとめたものです。
Discuss on Twitter • View on GitHub