エリック・エヴァンスのドメイン駆動設計を読んでいる ( 3 )

ユビキタス言語、声に出してモデリングする、１つのチームに１つの言語

ユビキタス言語、モデルの作成/更新はとにかく開発者とドメインエキスパートでずれないようにという話。

モデルにもとづいた会話のためのツールは、特になんでも良い
会話でも。ただ、コミュニケーションのあらゆる媒体に仕込む
ドメインエキスパート、開発者の間がそれぞれ「あいつら業務/技術の事よくわかってないだろう」という感じで細かいことを言わないと、亀裂が入りモデルが出来上がらない
最悪なのは、同じ言葉でドメインエキスパートと開発者の間で意味が違うのを認識しつつ許しちゃう事
> アプリケーションの限られたスコープや開発者の理解をはるかに超えた専門用語は、ほぼ間違いなくユーザにもあるだろう。しかし、そうした専門用語は言語が拡張されたものでしかない。こうした方言は、同じドメインに関して、異なるモデルを反映した別の語彙を含んでいてはならないのだ

この文の意味がわからなかった。つまり、技術的な用語は含んではならないって事か？開発者とドメインエキスパートの間で分かり合える用語に落とし込む？のか
モデルとコードは共同体。モデルが変わったらコードも変わらないとおかしい
ドメインエキスパートがモデルを意識できないなら、モデルがおかしいと考える
ドキュメントは最小限に。実体と離れがち

ドキュメントと図

UML図に頼りすぎないこと。情報が多すぎ/少なすぎて、議論の場で一時的に使うことは良いにしてもモデリングをこれだけで進めるべきてはない。

設計 = 結局はコード
適切に書かれたJavaは（Java推しか）、豊かな表現力がある
一度永続化したドキュメントは、進捗との繋がりを失ってしまう
わかる…。つまり、可能な限りはドキュメント化すべきものをコードに落とし込むべきだと思う。
これに対するアプローチは次の章で・・・