大規模な構造 (P439) †
要約 †
数千人もの人々が個々にAIDSメモリアルキルトを作りあげていった。
衛星通信システムのシミュレータを作るプロジェクトにて、MODEL-DRIVEN DESIGNで開発を進めていった。
モデル内の複雑な関係を明らかにするため分解して管理できるサイズのMODULEを沢山作ったところ、開発者たちは混乱してしまった(この機能はどのパッケージにあるのか？新しいクラスはどこに置くか？...etc)。
プロジェクトリーダーたちは、より複雑になっても把握できるよう設計をまとめ上げる方法を求めてた。
ブレインストーミング後、別のパッケージングの仕組みを考えクラス図を書いたがまだ満足しなかった。
シミュレーションの簡単な流れは把握しており、個々の詳細についてもモデルの中に在ったが、概要を把握することはできなかった。
ドメインからのいくつかの本質的な概念が失われ、全体としてモデルの構造が失われてしまった。
開発者たちはじっくり考え、設計に構造を押し付けていることが分かり、シミュレータ全体を一連のレイヤとしてとらえることにした。
新しい構造に合うよう、またMODULESがレイヤをまたがらないようにコードをリファクタリングしたところ、レイヤの定義やMODULEがどんどん洗練されていった。
レイヤはコード内のMODULEなどではなく、他システムとの境界や関係を制約する一連のルールだった。
これにより設計が十分に理解しやすくなり、全員が各機能について大体把握し個々に作業を行い、全体的な設計の決定を行うことができた。
大規模なモデルをMODULE分割すると数が多く複雑になり、必ずしも設計を均一にするわけではない。
BOUNDED CONTEXTSで厳密に分離を行うことで腐敗や混乱を防ぐが、システム全体を理解しやすくしてくれるわけではない。
CORE DOMAINに集中することで、サブドメインを脇役においやることは出来るが、CORE DOMAINとの関係などは把握しておく必要がある。
どんな規模のプロジェクトでも個々に作業を行うことがあるため、協調やルールがなければ全体像を把握できなくなる。
大規模なシステムにおいて、全体の設計に関わる要素について理解するための何らかの包括的な原則がなければ、開発者は細部にとらわれてしまい全体を見ることが出来ない。
「大規模な構造」は大まかな行程においてシステムについて議論や理解を促す言語である。高レベルの概念やルールはシステム全体の設計のパターンを確立する。
全体のシステムに渡り、(個々の責務に関する詳細な知識がなくとも)全体の各部分についていくらか理解できる役割や関係、およびルールのパターンを考えてみよう。
構造は1つのBOUNDED CONTEXTに収まるかもしれないが、通常は1つ以上にまたがってチーム全体や関連のサブシステムを把握ために概念をまとめてくれる。
ほとんどの大規模な構造はUMLで表すことができず、する必要もない。モデルや設計を形づけたり説明したりなど、コミュニケーションを促進するものである。
チームの規模がかなり小さくモデルがそれほど複雑でない場合、MODULESへの分解、充分な蒸留、開発者間での普段の調整によりモデルを組織化し続けられる。
大規模な構造はプロジェクトを収拾し、不適切な構造は大幅に開発を遅らせてしまう。この章では、大規模レベルの設計を上手く構築するためのパターンを模索していく。
担当者のつぶやき †
- 空気読まずに、そのまま「大規模な構造」と訳しました。文脈上「全体をくまなく捉えるための構造」みたいな感じスかね。scaleを地図などの「縮尺」という風にとらえるのがいいのかな？(でもピンとくる訳が思いつかず)
みんなの突っ込み †
