エリックエヴァンスのドメイン駆動設計を読んでいます。第1章第2部のまとめと感想をつらつらと書きます。感想は斜体で書いてみてます。

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

ユビキタス言語の重要性についてが語られている。

それぞれ異なる背景を持った開発者やドメインエキスパートがモデルの知識を蒸留していく過程において、用いる言語が統一されたユビキタスなものではなくてはいけない。

そうではない場合どうなるか？

そうでない場合は議論の中で、それぞれが使う言語を相手が理解できるように翻訳する必要が出てくる。これは手間であるし、そもそも翻訳が間違っていて正しく知識を伝えることができなかったりもする。

すると知識を蒸留していく中でズレが生じ、精製されたモデルに正しく知識が反映されていない状態になる。モデルはそのままコードに反映されるため、得られるプロダクトは的外れなものになる可能性がある。

コミュニケーションミスを減らす意味でも、コストを減らす意味でもユビキタス言語が大切になる。ドメインモデルはそのユビキタス言語の基盤となる。ドメインモデルに、モデルが従うべきルールやドメインモデルに対して適用されるパターンの名前によってユビキタス言語は構成される。

そのためチームのメンバーはこれらの概念を理解している必要があるのではないかと考えるのですが、ドメインエキスパートにそれを求めてもなかなかハードルが高いのではないですかね。各現場ではどうやっているのだろう。というかうちではどうやってるのだろうか。確認してみよう。

ユビキタス言語を使って議論をしていくわけだが、その中である単語がどうにもしっくりこない場面があるだろう。その場合はユビキタス言語を更新するわけだが、その際には同時にモデルも変更されるという点を意識する必要がある。しっくりこないようなモデルは使い続けるべきではなく、フィードバックを受けて改良されるべきだからだ。

声に出してモデリングする

モデルを中心に会話をしていくことが大事だと述べられている。声に出すことで話していることが整理できるという経験はいくらでもあるし、議論を行う上で一番優れているのは直接会話することだと思うので、会話することが大事であるというのはその通りなんだと思う。

ドキュメントと図

モデルを図示するにあたり、全ての要素を詳細に図示する必要はないということが述べられている。詳細はコードが示すので、モデルでは大切な考え方の骨格を提供することが肝要だ。うちの現場ではモデルを概念モデルと詳細モデルに分けているが、詳細モデルであっても全ての詳細を書き出したりはしない。概念モデルはその名前の通りモデルの相互作用を表した概念を示すものであり、詳細モデルは開発する上で参考にするハンズオンなモデルという位置付けという感じにしていたはず。概念モデルとか詳細モデルとかってこの本で後々出てくるのかな？まあ読み進めてみます。