DDDについての覚書

　少し前のことだが、.Net Rocks! というオンライントークショーのサイトに『Domain-Driven Design』の著者Eric Evansのインタビューが上がっていたので、今になってiPodに入れて通勤の行き帰りに聴いている。
http://www.dotnetrocks.com/default.aspx?showNum=236

　インタビューの中で非常に印象的だったポイントを2つ、覚書として書いておきたい。

- DDDだからといって、全部ドメインモデルで構築するものだと思い込むのは間違い
- 重要なのは、開発手法としてのアジャイルではなくて、ビジネス本来のアジャイルさ（変化のスピード）についていくこと

Martin Fowler, Eric Evans

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

全部ドメインモデルで構築するものだと思い込むのは間違い
　DDDはFowlerの『エンタープライズ アプリケーションアーキテクチャパターン』との関連が深く、Domain Modelパターンを深く掘り下げたものという評価があるため、ドメインモデルを使わなければいけないものだと思ってしまうが、実はそうではないらしい。

　重要なのは「フォーカス」であって、アプリケーション全体を精密にモデリングしようとするのは、よくある間違い。ビジネスにとって最も価値のある部分に全力を投入して、そこだけはリッチにドメインモデリングして他社との差別化を図るのが正解。その他、定型部分やビジネスにとって価値のない部分は、Transaction Scriptを使うなり、Smart UIを使うなり、パッケージ製品を買うなりして、ローコストに瞬殺する。ビジネス価値のないところに、経営資源を投入してはいけない。

　というわけで、DDDを実践するときに大事なのは、アプリケーションのどの部分がドメインモデルを使って全力を投入すべき箇所なのかを嗅ぎ分ける、アーキテクト的な嗅覚ではないだろうか。

開発手法としてのアジャイルではなくて、ビジネス本来のアジャイルさ
　DDDはテストファーストやオンサイト顧客、継続的統合など、XP的なアジャイル手法を多く取り入れている。なので、やっぱりDDDはアジャイル手法の肩をもつのか、というと必ずしもそうではない。

　DDDが大事にしたいのは、方法論としてのアジャイルではなくて、ビジネスそのもののアジャイルさ（変化のスピード）だ。技術ではなく、あくまでビジネスが大事。ビジネスは、市場の変化や政府による規制、M&Aなど、刻一刻と状況が変化していて、それに素早く対応できるプレイヤーだけが成功できる。そうした競争に勝ち残れるビジネス的な価値提供を支援するのが、DDDだ。ビジネスのアジャイルさに追従できる、現在最善のアプローチがアジャイル手法なので、アジャイル手法が積極的に採用されているわけだ。

　この点に限らず、DDDでは、これまで技術的な文脈でのみ考えられてきたプラクティスを、ビジネス的文脈で捉え直す、という考え方のクセが随所に見られる。例えばモジュールの考え方をドメインの視点から見直すとか、高凝集／低結合の考え方を概念的な意味において再発見するとか。