Comment評判高いのに、なぜか日本語訳が出ないので原書で。見る現在第8章まで読了。読んでいて共感できたのは、「ユビキタス言語(共通言語)」という概念。顧客も、ドメイン専門家(コンサルタントかな?)も、設計者も、そしてコーダーも、全員がそのドメインを理解するための「共通言語」を持たなければならない。それがユビキタス言語。それらの言語を用いて、ミーティング、設計、コーディングすることで、全ての人がドメインに対する共通理解を深めていくことができる。顧客とのミーティングでよく出てくる用語を、現在のモデルが含んでいなければ、それはモデルが不十分であることを表す。Endで徹底されているかというと、そうじゃないからなぁ。モデルというのは、UMLで記述された「図」のみを意味するのではないというのも重要。それはあくまでモデルの一部分。モデルは様々なドキュメント、コードから構築されている。重要なのは図を描くことではなく、正しいモデルを設計し、皆で共有すること。今読んでいる第8章は、リファクタリングによって、モデルが劇的に改善される「ブレークスルー」といわれる局面について。劇的なモデルの変更は、それがいかに良いモデルであっても、よいことばかりではない。作成済みのモデルやコードを修正、場合によっては捨てなければならない。技術的なことではないのだが、筆者がこの章で書いている、プロジェクト・マネージャーの逸話がすばらしかった。プロジェクト・マネージャーにとっても、ある程度スケジュールが進んだ段階での、モデルの劇的な変更はリスク。この章で登場するマネージャーは、以下を確認した上で、モデルの変更にGoを出している。このモデル変更が必要なのか、モデル変更しない場合、何が問題になるのか変更する場合のリスクは何か変更するのに必要な期間はどれくらいか単に相手の意見を受け入れるだけでもなく、また、リスクを避けるために頭ごなしに拒否するわけでもない。良い物ができるのであれば、リスクをとるべき、と判断している。プロジェクト・マネージャーの鏡だなぁ。コメントをキャンセルメールアドレスが公開されることはありません。ThemeHall.。