評判高いのに、なぜか日本語訳が出ないので原書で。
Domain-Driven Design: Tackling Complexity in the Heart of Software
- 作者: Eric Evans
- 出版社/メーカー: Addison-Wesley Professional
- 発売日: 2003/08/22
- メディア: ハードカバー
- 購入: 4人 クリック: 113回
- この商品を含むブログ (89件) を見る
現在第8章まで読了。
読んでいて共感できたのは、「ユビキタス言語（共通言語）」という概念。
顧客も、ドメイン専門家（コンサルタントかな？）も、設計者も、そしてコーダーも、全員がそのドメインを理解するための「共通言語」を持たなければならない。それがユビキタス言語。
それらの言語を用いて、ミーティング、設計、コーディングすることで、全ての人がドメインに対する共通理解を深めていくことができる。顧客とのミーティングでよく出てくる用語を、現在のモデルが含んでいなければ、それはモデルが不十分であることを表す。日本のSIでもプロジェクト用語辞書作ったりするけど、End To Endで徹底されているかというと、そうじゃないからなぁ。
また、モデルというのは、UMLで記述された「図」のみを意味するのではないというのも重要。それはあくまでモデルの一部分。モデルは様々なドキュメント、コードから構築されている。重要なのは図を描くことではなく、正しいモデルを設計し、皆で共有すること。（もちろん、そのツールとしてUMLは有用）
第8章
今読んでいる第8章は、リファクタリングによって、モデルが劇的に改善される「ブレークスルー」といわれる局面について。
ただ、劇的なモデルの変更は、それがいかに良いモデルであっても、よいことばかりではない。すでに作成済みのモデルやコードを修正、場合によっては捨てなければならない。
技術的なことではないのだが、筆者がこの章で書いている、プロジェクト・マネージャーの逸話がすばらしかった。プロジェクト・マネージャーにとっても、ある程度スケジュールが進んだ段階での、モデルの劇的な変更はリスク。この章で登場するマネージャーは、以下を確認した上で、モデルの変更にGoを出している。
- なぜこのモデル変更が必要なのか、
- モデル変更しない場合、何が問題になるのか
- 変更する場合のリスクは何か
- 変更するのに必要な期間はどれくらいか
単に相手の意見を受け入れるだけでもなく、また、リスクを避けるために頭ごなしに拒否するわけでもない。より良い物ができるのであれば、リスクをとるべき、と判断している。プロジェクト・マネージャーの鏡だなぁ。
