戦略的デザインに関する意思決定のための６つのエッセンス

Eric Evans氏の名著"Domain-Driven Design"第17章より、戦略的デザイン（"Strategic Design"）のためのエッセンスをまとめた部分について要約とコメント。

Six Essentials for Strategic Design Decision Making

決定はチーム全体に行き渡らなければならない
戦略はメンバー全員が知る必要がありますが、かといって中心にすえられるのが「象牙の塔のアーキテクト」だとうまくいきません。コミュニケーションがうまくいっているプロジェクトでは、アプリケーションチームから発生した戦略的デザインこそが全体に行き渡り、正しい意思決定をする上での権威を持ちます。どんなシステムであっても大切にしなければいけないのは、マネジメントによって与えられた権威よりも開発者が戦略に対して持つ実際の関係なのです。

決定のプロセスはフィードバックを吸収しなければならない
ドメインに関する深い知識を持っているのはアプリケーションチームです。だから、アーキテクチャチームがつくったアーキテクチャではうまくいかないことが少なくありません。戦略的デザインは開発全体に影響を及ぼしますが、技術的なインフラやアーキテクチャと違ってそれほどコードを書きません。巻き込むべきなのはコードを大量に書ける人ではなく、アプリケーションチームです。熟練したアーキテクトならば、発想を吸い上げて全体に適用できるソリューションを見いだすことができます。

計画は進化を許容しなければならない
効率的なソフトウェア開発というものは極めてダイナミックなプロセスです。もし高度な意思決定が固定してしまっては、後の変化に対応するための選択肢が狭まってしまいます。「発展する秩序（"EVOLVING ORDER"）」によって、洞察の深まりに呼応した変化に対応することができます。全体を調和させるという原則は大事ですが、それは開発に合わせて変化しなければならないし、またそれを理由にアプリケーション開発者から自由を奪ってはいけません。強力なフィードバックによってこそ、障害に突き当たった時や予期せぬチャンスが見つかった時にイノベーションが起こるのです。

アーキテクチャチームが優秀な人材を吸い上げてはいけない
このレベルのデザインができる人は限られています。マネージャは優秀な開発者をアーキテクチャチームやインフラチームに入れようとしますし、それは開発者本人の意思に添うものでもあります。その結果、アプリケーションチームに技術的に劣った開発者しか残らなくなることがしばしばあります。しかし、良いアプリケーションを作るのにも技術がいるのです。逆に、これではアーキテクチャ／インフラチームに、技術はないかもしれないけれどもドメインに詳しいという人が入りません。戦略的デザインは純粋な技術タスクではないので、ドメインに対する深い知識を持った開発者も、ドメインエキスパートも必要です。つまり、アプリケーションチームには優秀な設計者が必要ですし、戦略的デザインにはアプリケーションチームが持つドメインの知識が欠かせません。

戦略的デザインにはミニマリズムと謙虚さが必要だ
本質を抽出することとミニマリズムはどんなデザインにおいても本質的ですが、戦略的デザインにとってミニマリズムは殊更に重要です。アプリケーションとのわずかな不整合も致命傷になり得るのですから、アーキテクチャチームがアプリケーションチームと分かれている場合には特に注意しなければなりません。また、アーキテクトが使命感からやりすぎてしまい、結果として生産性を下げるケースを何度も見てきましたし、やってしまったこともあります。デザインを明確にするものだけしか含めないように自分を律しなければいけません。自分が最も優れていると思うことが誰かの邪魔をするかもしれない可能性を認識するには謙虚さが必要です。

オブジェクトはスペシャリストだが開発者はジェネラリストである
優れたオブジェクトデザインの本質は各オブジェクトに対して明確に限定された責務を割り当てることであり、相互依存関係を極限まで少なくすることです。このことから時にチーム間の関係も同じように限定しようとしてしまうことがあります。良いプロジェクトは、開発者がフレームワークに関わる一方でアーキテクトがアプリケーションコードを書くといった具合にもっと混沌としているもので、それで効率的なのです。戦略的デザインとそれ以外のデザインを区別してきましたが、それに携わる人を区別しろということではありません。個人が把握できることに限界はありますが、だからと言って過度に専門を分けすぎてしまうとドメイン駆動デザインの力を削いでしまいます。

コメント

まずは「戦略的デザイン」の定義から。巻末の用語集にはこう書かれています。

strategic design Modeling and design decisions that apply to large parts of the system. Such decision affect the entire project and have to be decided at team level.

戦略的デザイン モデリングとデザインに関する決定の中でシステムの大部分に適用されるもの。このような意思決定はプロジェクト全体に影響を及ぼすものであり、チームレベルでなされなければならない。(p.512)

実際に本の中で戦略的デザインのパターンとして紹介されているものは、どれも技術的な観点から生まれたものではなく、「モデル」を明確にするためのパターンであると言えます。

その上で内容を振り返ると、繰り返し強調されているのが「アーキテクチャ／アプリケーション」という二項対立に対するアンチテーゼです。これはそもそもDDDが書かれた意図を考えれば、当然のことであると考えられます。

Yet the most significant complexity of many applications is not technical. It is in the domain itself, the activity or business of the user.

しかし、多くのアプリケーションが持つ複雑さの中で最も重要なのは技術的なものではありません。これはドメインそれ自体、つまりユーザの活動やビジネスの中にあるのです。（p.xxi）

つまり、ドメイン自体が持つ複雑さにどう対処するのかを考えるドメイン駆動デザインにとって、「ドメインから切り離されたアーキテクチャチーム」はそもそもナンセンスなものなのです。

しかし、今回とりあげた６つのエッセンスが提示しているテーゼは、「アジャイル」や「ドメイン駆動」という文脈を外して考えても色々と問題を投げかけてくるように思えます―アーキテクトはひとりよがりになっていないだろうか？アーキテクチャチームとアプリケーションチームで責任のなすり付け合いをしていないだろうか？アプリケーション開発者は業務について深く理解しているだろうか、少なくとも理解しようとしているだろうか？

---

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