Domain Driven Design

評判高いのに、なぜか日本語訳が出ないので原書で。

Domain-Driven Design: Tackling Complexity in the Heart of Software

Domain-Driven Design: Tackling Complexity in the Heart of Software

現在第8章まで読了。

読んでいて共感できたのは、「ユビキタス言語(共通言語)」という概念。

顧客も、ドメイン専門家(コンサルタントかな?)も、設計者も、そしてコーダーも、全員がそのドメインを理解するための「共通言語」を持たなければならない。それがユビキタス言語。

それらの言語を用いて、ミーティング、設計、コーディングすることで、全ての人がドメインに対する共通理解を深めていくことができる。顧客とのミーティングでよく出てくる用語を、現在のモデルが含んでいなければ、それはモデルが不十分であることを表す。日本のSIでもプロジェクト用語辞書作ったりするけど、End To Endで徹底されているかというと、そうじゃないからなぁ。

また、モデルというのは、UMLで記述された「図」のみを意味するのではないというのも重要。それはあくまでモデルの一部分。モデルは様々なドキュメント、コードから構築されている。重要なのは図を描くことではなく、正しいモデルを設計し、皆で共有すること。(もちろん、そのツールとしてUMLは有用)

第8章

今読んでいる第8章は、リファクタリングによって、モデルが劇的に改善される「ブレークスルー」といわれる局面について。

ただ、劇的なモデルの変更は、それがいかに良いモデルであっても、よいことばかりではない。すでに作成済みのモデルやコードを修正、場合によっては捨てなければならない。

技術的なことではないのだが、筆者がこの章で書いている、プロジェクト・マネージャーの逸話がすばらしかった。プロジェクト・マネージャーにとっても、ある程度スケジュールが進んだ段階での、モデルの劇的な変更はリスク。この章で登場するマネージャーは、以下を確認した上で、モデルの変更にGoを出している。

  • なぜこのモデル変更が必要なのか、
  • モデル変更しない場合、何が問題になるのか
  • 変更する場合のリスクは何か
  • 変更するのに必要な期間はどれくらいか

単に相手の意見を受け入れるだけでもなく、また、リスクを避けるために頭ごなしに拒否するわけでもない。より良い物ができるのであれば、リスクをとるべき、と判断している。プロジェクト・マネージャーの鏡だなぁ。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です