DDD 読書会 #1(後半の裏)
さて、間が空いてしまいましたが、前回の続きです。やる事が溜まりすぎて追いついていませんが、なんとかして続けて行くつもりなので、なま温かく見守っていただけたらと思います。
2章 Communication and the Use of Language
今回はドメイン駆動設計で提案する原則の中でも特徴的な、ユビキタス言語の章についてです。
ユビキタス言語について
2章の前半はユビキタス言語の考え方と、そのメリットについて書かれていました。
1章ではチームのメンバー(=開発者とドメインエキスパートの両方)が、ソフトウェアのモデルを議論しながら作り上げていくことを提案していました。繰り返しではありますが、「ドメインエキスパート」はユーザーやお客さんのような「ソフトウェアでやりたい事を最も理解している人」といった意味です。
しかし「開発者とドメインエキスパートがソフトウェアについて議論する」事は非常に難しいです。仕事で開発をしている人は誰もが経験があるのではないでしょうか。現実では「設計担当がお客様の要件を解釈して、実装設計する」というのが典型的な方法だと思うのですが、どこも認識違いや意思疎通の難しさで苦労しているようです。昔からこんな絵もあるくらいです。
参考: ITプロジェクトの実態とは！ | cagylogic Project Cartoon: Japanese
そこで、ドメイン駆動設計では、従来の「開発者がドメインエキスパートの話を『翻訳』する」という形をやめて「開発者とドメインエキスパートの両方が歩み寄って、同じ用語を使う。その用語はそのまま実装(クラスとメソッド)にも使う」という方法を提案しています。この用語をユビキタス言語と呼びます。ユビキタス言語で対話をする事で意思の疎通がしやすくなり、知識の咀嚼を効率的に行うことができるようになるそうです。
しかし、開発側からすれば「クラスやメソッドの話をお客さんにしても理解できない」と思うのではないかと思います。それに対しては、筆者は「理解できないのは大抵はモデルが悪いことによる」「モデルが妥当かについて最も詳しいのはドメインエキスパートである」という意見を述べています。ここら辺の具体的な方法は、「詳しくは後の章で!」といった事なのでしょう。
また、前半で個人的に興味深かったのが、ユビキタス言語と実装を一致させるメリットです。クラスやメソッドを会話に用いる事で、設計に無理が無いかどうかを検証できるそうです。実際の所、設計の検証方法は「経験と勘」か「実際に書いてみる」しか思いつかなかったので、目から鱗でした。
ドキュメントおよび図について
この章の後半は、ドキュメントや図(特にUML)について書かれていました。
筆者のスタンスは「コードが最も正確なドキュメントである」という事です。これは、いわゆるアジャイルな開発手法ではよく言われている事であると思います。とはいえ、大抵のアジャイル開発手法で注意書きがされるように、ドキュメントを作る必要がないという意味ではありません。ただ、会話とコードによる説明を正とするべきであって、ドキュメントをモデルの定義とする事を否定しています。
具体的には、ドキュメントや図はコードと会話の補足説明としてホワイトボードに書いたりする事が効果的との事です。また、ドキュメントを残す場合は、常に最新にし、実装との矛盾が無いように管理しておくべきと主張しています。一方で、コードの方でも変数名等が実際と乖離することがあるので、可読性をあげる事を強調していました。
後半は比較的実践しやすい内容であるように思いました。実際、詳細設計が必要なかったり、必要とされていても実質使用されていない、というケースも多いのではないか(環境次第でしょうが…)と思います。
さて、これでやっと1回のDDD読書会の内容は終了です。現時点で3回終わっていて、周回遅れどころじゃなくなっていますが…。書ききれない部分や説明が下手な所が多いと思いますので、興味のある方は購入する事をお勧めします。
