DDD の勉強始めます

新卒研修を受ける中で DDD が出てきて、勉強したくなったので、
『エリック・エヴァンスのドメイン駆動設計』（エリック・エヴァンス著，今関 剛 監訳，和智 右桂、牧野 祐子 訳） を読んでいこうと思います。

今回は第1部「ドメインモデルを機能させる」の 1章 と 2章 をまとめます。

注意： 僕の理解をそのままメモとして書き連ねていきます。
したがって、誤った理解もあると思うので、そのときはDMとかでご指摘お願いします！

1章 知識をかみ砕く

ソフトウェアを作るときに、はじめから対象を十分に理解している開発者などいない。

対象 ＝ これから作るソフトウェアで実現する作業 ＝ ドメイン

したがって、対象について詳しい人（ドメインエキスパート）と開発者で
十分に話し合って理解を深めることが重要である。

理解したことはモデルとして書き出す。
そして、ドメインエキスパートは足りないところがあれば追加で説明する。
開発者は分からないところがあれば質問する。

上記工程を何度も繰り返し、その都度得た知識をモデルに落とし込んでいく。
→ 継続的学習（継続的学習は開発が始まった後でも行う）

はじめから対象を如実に表したモデルを作れることは滅多にない。

ドメインエキスパート と 開発者 では見ている視点が違うので少し話を聞いたぐらいで
完璧なモデルを作ることができないのは当たり前である。

だからこそ、対話を通して、互いに疑問点や不要な点を洗い出し、洗練する必要がある。
これが 知識のかみ砕き である。

1章 まとめ

• ドメインエキスパートと開発者が話し合ってドメインをモデルに落とし込んでいく
  • 用語の説明や不足点の追加など とにかく話す
  • ドメイン：ソフトウェア化する対象（業務やサービスなど、ソフトウェア化の対象となりうる万物）
• 一発で完璧なモデリングはできないから、継続的に改善していく

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

ドメインエキスパートが使う専門用語を開発者は理解できないし、
開発者が使う専門用語をドメインエキスパートは理解できない。

ドメインエキスパートと開発者の両者が同じ意味だと思って使っていたとしても
たいていの場合、差異がある。

このような差異があると 通訳 が必要となる。
通訳はコミュニケーションを鈍らせ、知識のかみ砕きを沈滞させる。

共通言語としてのモデル

通訳をなくすために、 モデルを言語の骨格として使用 する。

ドメインエキスパートと開発者のコミュニケーションやコード、ドキュメント、図など
全てにおいて、その言語を使用する。

ここで、モデルはドメインエキスパートと開発者のコミュニケーションから生まれることを思い出す。

つまり、コミュニケーションの中で認識の違いが見つかるなどして、
言語定義に対する変更があったときにはモデルが変更になり、
さらにはコード中のクラス名やメソッド名が変わることもありえる。

こうすることで、
ドメインエキスパートと開発者は、ともに不正確なところや矛盾を指摘し合い、
より確かなドメインモデルを構築することができる。

こうして作成されたモデルをドメインエキスパートが理解できなかった場合、
そのモデルには何か問題があることがわかる。

つまり、実現したいソフトウェアではないということになる。

図とドキュメントに関する注意点

ここでいうドキュメントとは開発者側でのみ使用するドキュメントだと思われる

設計に関する本質的な詳細は、コードにおいてとらえられる。
したがって、図でモデルを表現はしないし、ドキュメントによって全て説明しようとはしない。

モデル ≠ 図

図はモデルについてのコミュニケーション、説明を助けるために使う。

ドキュメントはコードと会話の補足事項のみを記述する。

ドキュメントは常に最新である必要があるから、
補足事項以外も含めて全てドキュメント化するのはつらい的な意味合いに感じた。

なにより先述したとおり、「設計に関する本質的な詳細は、コードにおいてとらえられる」から。
XP を代表とするいくつかの手法では、コードで全てを語る。

2章 まとめ

• ドメインエキスパートと開発者の共通言語は、ドメインモデルを言語の骨格として使用する

  • そこで理解できないことがあれば、モデルのリファクタリングが必要

• 図とドキュメントはあくまで補助資料。コードで語ろう。