エリックエバンスのドメイン駆動設計の「第16章 大規模な構造」まとめ

エリック・エヴァンスのドメイン駆動設計

エリック・エヴァンスのドメイン駆動設計

今回は、「第16章 大規模な構造」のまとめです。

概要

巨大なシステムに包括的な原則がなく、各要素を解釈する際に、設計全体にまたがるパターンにおいてどのような役割を果たすかという観点から考えることができなければ、開発者は「木をみて森を見ず」になってしまいます。

そのため、全体の詳細を徹底的に調べなくても、全体の中で個々の部分が果たす役割を理解できる必要があります。

「大規模な構造」は、システムをおおよその構造から議論し、理解できるようにするための枠組みです。

大規模な構造を使用するという選択は、個別の部分を最適に構造化するよりも、モデル全体としての扱いやすさを優先するということです。

また、大規模な構造を適用すべきなのは、モデルの開発に不自然な制約を強いることなく、システムを大幅に明確化する構造が見つけられた時だけです。

進化する秩序

設計に制約がなければ、出来上がるシステムの全体像が誰にも理解できない上に、保守するのも非常に困難になります。

ただし、設計上の意思決定の融通が利かないアーキテクチャは、要件が変化し、ドメインに対する理解が深まるにつれ、開発者を束縛することになります。

そのため、ドメインに関する実際の経験と知識に基づいて構造を選択し、過度に制約的な構造を避けることが重要です。

責務のレイヤ

ドメインモデル内にある概念上の依存関係を調べて、自然な階層が認められたら、階層に抽象的な責務を割り当てを実施します。

階層は、ドメインの基本的な現実や優先事項を伝える必要があります。

また、階層の責務を決める際は、技術的な意思決定というより、ビジネス上の意思決定で行います。

具体的なイメージは、本書から以下を抜粋します。 f:id:mmm-mao:20150715090321j:plain

本書に紹介されている抽象的な責務は以下の通りです。 f:id:mmm-mao:20150715091347j:plain

知識レベル

他のオブジェクトグループがどう振る舞うべきかを記述するオブジェクトであります。

例えば、従業員タイプや会員タイプなどが知識レベルで、従業員や会員が業務レベルの内容になります。

僕は普段Javaで開発しているんですが、enumを利用するケースは、知識レベルの内容になると思います。

f:id:mmm-mao:20150715092305j:plain

まとめ

f:id:mmm-mao:20150715083840j:plain

以上が「第16章 大規模な構造」のまとめです。