DDD
EVOLVING ORDER (p.444) †
要約 †
EVOLVING ORDER （発展する秩序）
[問題についての説明]
- 無秩序な設計を避けるために、開発者を様々な形で束縛するアーキテクチャを設定するものだ。技術的な部分に関してはこれもよいのだが、アプリケーションやドメインモデルの領域に関しては問題が生じる。つまり、開発者が特定の課題に対して適切な設計を行うことを妨げるし、場合によってはプログラミング言語に関する知識や技術までも奪い去ろうとする*1。技術的なものであってもドメインに関するものであっても、こういったアップフロントなアーキテクチャは後の変更やリファクタリングに対する拘束衣("straitjacket")となってしまう。
- J2EEのような技術的なアーキテクチャは普及してきたが、大規模な構造についてはそうでもない。
- アップフロントな大規模構造の設定にはコストがかかるようだ。開発の進展に合わせてリファクタリングしたくなった時、どうにかしようとしたり、アーキテクトと交渉したりすれば開発ペースは落ちるが、マネージャはアーキテクチャはできあがっていると考える。「なんでアプリケーションを作らないで、アーキのことをどうこう言うんだ？」と。仮にマネージャやアーキテクトが物わかりが良くても、変更する作業自体、骨が折れるものだ。
問題サマリ
- 誰も全体像が分からない、なんでもできてしまうシステムを設計してしまうと、メンテナンスが非常に困難になってしまう。しかしアーキテクチャはプロジェクトをアップフロントな設計上の推測によって拘束してしまい、アプリケーションの特定の領域において、開発者や設計者が持つべき力を奪ってしまう。そこで開発者がやることというのは、アプリケーションを無理矢理構造に合わせるか、構造をひっくりかえして無秩序な状態に戻してしまう。
[問題の解決方法についての説明]
- ガイド的な規約があることが問題なのではなくて、厳しすぎたり出所が怪しかったりすることの問題なのだ。規約が現実に即したものならば、助けになると同時に標準化も促進される。
Therefore:
- 概念的な大規模構造をアプリケーションと共に発展させなさい。その過程で全く違う構造になるかもしれない。詳細な設計やモデルの決定を過度に束縛してはいけない。それは詳細な知識に基づいて作られなければいけないのだから。
- 全体の論理は個別の箇所には当てはまらない。大規模構造を選択するということは、個別の理想的な構造よりも全体の管理しやすさを優先するということ。だから、全体の統一性と個別最適化との間には妥協しなければいけないものがある。しかし、実際の経験とドメインに対する知識に基づいた構造を選択し、過度に縛るような構造を避けることによって、ある程度は緩和することができる。（強調訳者）ドメインと要件に本当にマッチした詳細なモデリングと設計を容易にする。
- 大規模構造は同時に、個別の設計における判断を容易にする。もちろんリファクタリングは必要だが、そのプロセスは遥かに管理しやすいものになる。
- 大規模構造はBOUNDED CONTEXTをまたがって適用される必要がある。また、イテレーションを通じてCONCEPTUAL CONTOURSに対応するものへと発展していく。モデルについて推測するなということではないが、個々のCONTEXTにいる開発者に自由を与えよということだ。
- 同時に大規模構造は開発に実際の制約を与えなければならない。例えば開発者がシステムのある部分に手を加えてはいけないということもある。こういう場合には、特定の外部要素にあうよう構造を変えたり、アプリケーションと外部との関連方法を特定したり、あるいは現実に合わせて構造を緩くしたりすることで対応できる。
- CONTEXT MAPと異なり、大規模構造は必須ではない。MODULEに分解してもシンプルであるようなシステムには必要ない。大規模開発が適用されるのは、モデル開発に不要な制約を与えずに、システムが極めて明快になるような構造が見いだされる時である。マッチしない構造が最悪なのだから、分かりやすさよりも問題を解決する必要最小限のものを見つけなさい。Less is more.
- 大規模構造は有益だが、例外もある。例外は見えるようにしなければならず、あまりに増えてきたら構造を変えるか、捨てるかしなければならない。
＊＊＊
無秩序を防ぎつつ開発者に必要な自由を与える構造というのは相当な偉業である。技術的なアーキテクチャに関しては多くがなされているが、ドメインレイヤに関して公開されているものは少ない。アプリケーションタスクやユースケースによってドメインをブレイクダウンすることで、オブジェクト指向パラダイムを弱めてしまうものもある。まだまだ手が付けられていない領域だが、自分の経験から４つのパターンについて議論していく。
担当者のつぶやき †
- 一言で言うと「全体像は決め打ちしない。流れの中で現れてくるもの」ということでしょうか。
- 言っていることは良く分かるし、理想的だとも思いますが、敷居高過ぎです。。。ただ開発者をガチガチに縛るアーキテクチャが本当は良くないことは分かっていることなので、一度位は冒険してみたいものですね。
みんなの突っ込み †
- この章だけだと、具体例がないのでますます現実味がないですねぇ… -- 渡邉?
- p.445 l.1 "The problem is not the existence of guiding rules"を何を寝ぼけたのか「ガイド的な規約が無いことが問題なのではなく」と訳していました。渡邉さんにご指摘頂き修正しました。m(_ _)m -- 和智?
