ravelll の日記

よしなに

エリック・エヴァンスのドメイン駆動設計 2章メモ

ユビキタス言語とそれを作る・使う上でのよくある勘違いの章と理解した。

第2章 コミュニケーションと言語の使い方

  • 言語はドメインに関する意思決定と実装を結ぶもの
    • 言語の乖離は実装の乖離に繋がりそう
  • ドメインエキスパートと開発者のそれぞれがドメインを記述する言語を独自に作り出してしまう
    • 翻訳が必要になるが、翻訳はモデルの概念を混乱させることに繋がり、混乱は破壊的なリファクタリングに繋がる
    • 通訳は知識の噛み砕きを鈍化させる
  • ちゃんとモデルに基づいた言語で会話をするように頑張らないと知識の噛み砕きのプロセスが良いモデルを作ることに繋がらなくなっていく
  • 実装に紐づく言語でみんながしゃべると不意に矛盾が見つかることが多くなって便利で、その一方で開発者の言葉をそのまま共通言語として採用するにはドメインエキスパート側の負担が大きいので双方から歩み寄った現実的な解としてのユビキタス言語という概念、という感じ?
  • 何でもかんでもユビキタス言語化するのではなく、あくまでもモデルが対象とする範囲においてユビキタス言語を作る、というのはなるほどという感じ
  • ユビキタス言語は開発者・ドメインエキスパートが理解するものの最大公約数となるような定義ではなく、厳密に限定された定義としなくてはならない
    • 両者が同じものを想像する程度に理解できる名前だからオッケーというものではない
  • UML はそれを書き出して議論に中心に置くことで統一した相互関係・モデル名を全員が持ち議論できるようにする = Unified Modeling Laungage
  • UML はそんなに完璧に詳細を書き出すものではない
  • UML はオブジェクトの属性と関係は容易に書き出せる一方でオブジェクトの振る舞いや制約は書き出しづらいツール
    • その限界をユビキタス言語を用いた会話によって補える
  • "モデルは図ではない"
    • 図は単にモデルについて議論する際にコミュニケーションや理解を円滑にするための表現の1つというだけ
    • 前職で開発の進行をやったときにすべてのモデルを言葉で表現しようとしたけど、もっと図を使ったり、複数の方向からモデル作成を試行してみればよかったな…
      • そもそもコミュニケーションが足りてなさすぎたのも問題だった

書かれた設計ドキュメント

  • ドキュメントが事実と乖離していく問題
    • XP => 極力書かずにコードに語らせる。コメントはこれに含まれないので重視しない
      • 厳密で活きたモデルを保てるが、理解しづらい。また背景を伝えられない
  • "すでにコードがうまくやっていることを、ドキュメントでもやろうとするべきではない"
    • ドキュメントはコードを補足する
  • ドキュメントはそれが必要なら乖離が問題として浮上する
  • 問題にならず乖離しているドキュメントは更新するのも時間の無駄
  • ユビキタス言語でモデルの背景となるビジネス知識などを共有することに成功するとモデルのドキュメンテーションを小さくすることができる
    • ドキュメントでコードと会話を補足する
  • "正しいことをするだけでなく、正しいことを言うコードを書くためには、潔癖でなければならない"
    • 前者だけではモデルとの繋がりが曖昧になる(名前が曖昧とか)
  • コードから何らかモデルを説明するもの(図とかテキストとか)を出力する方法は研究されていないのかな
    • コードを直接ドメインエキスパートが読むのは現実的には難しいけどそれを抽象化したものを使って会話ができると良さそうな気がする

説明のためのモデル

  • 実装、設計、コミュニケーションの根底にあるモデルはチームで1つにしよう
  • モデルのコアとなるものではなく一般知識を説明するためには別のモデルを利用できる
    • そのときにはコアとなるモデルと混同しないように UML は使わないほうが良い