支配せず、観察せよ

今日のシステムは分散化され、疎結合になっています。疎結合のシステムを作るのは少し大変な仕事になります。なぜわざわざそんなことをするのでしょうか。それは、システムを柔軟にして、少々の変更で空中分解するようなことのないようにしたいからです。これは、今日の環境で特に重要なポイントです。今日の環境では、私たちはアプリケーションのごく一部しかコントロールできません。他の部分は、分散サービスとかサードパーティーパッケージという形で、他の部門や社外のベンダーによってコントロールされているのです。

それなら、柔軟性が高く、時間とともに発展するようなシステムを作ればいいような感じがします。しかし、そうするとシステムが時間とともに変わることにもなります。「今日のシステムは昨日のシステムではない」というようなことになると、システムのドキュメントを作るのがとても難しくなります。ドキュメントは、印刷される頃には古くなっていることがよくありますが、始終変わるようなシステムでは、それどころの騒ぎではありません。

また、柔軟性の高いシステムを作ろうとすると、通常はアーキテクチャーがより複雑になり、定石に従って「大きな絵」をつかむのが難しくなります。たとえば、すべてのシステムコンポーネントが設定可能な論理チャネルを介して通信する場合、何が起きているのかをより完全に把握したければ、チャネルのコンフィギュレーションを覗いてみなければなりません。よくわからないままに論理チャネルにメッセージを送り込んでも、コンパイルエラーは起きないでしょうが、メッセージにカプセル化されたユーザーの意思は伝わらず、ユーザーをがっかりさせることになるでしょう。

何かと支配したがるアーキテクトは、時代遅れで、密結合のもろいソリューションを作ってしまいますが、逆に、ソフトウェアに無制限に動き回られたのでは、間違いなくカオスになります。計器なしで計器飛行するようなことを避けるために、コントロールの欠如を他の何かで補わなければなりません。

しかし、一体どのような計器があるというのでしょうか。実は、結構あるのです。今日のプログラミング言語にはリフレクションをサポートしていますし、ほとんどすべてのランタイム環境はランタイム統計を提供しています。システムのコンフィギュレーションの幅が広がれば、現在のシステム。コンフィギュレーションが大きな情報源になります。

大量の生データを理解するのは大変ですから、そこからモデルを抽出します。たとえば、どのコンポーネントがどの論理チャネルにメッセージを送っているかがわかり、どのコンポーネントがチャネルをリッスンしているかがわかったら、コンポーネント間で実際に行われている通信のグラフモデルを作ることができます。数分あるいは数時間ごとにこれを行えば、最新の正確なシステムのイメージが得られます。これは「リバースMDA」と考えることができるでしょう。モデルにアーキテクチャーを駆動させるのではなく、柔軟性の高いアーキテクチャーを作り、実際のシステムの状態からモデルを抽出するのです。

このモデルは簡単に視覚化することができ、そうすると文字通りの「大きな絵」が作れます。しかし、システムのすべてのクラスを含む3×5mのボックスと矢印の巨大ボードを作るのはやめた方がよいでしょう。コンテンポラリー・アートとしては通用するかもしれませんが、ソフトウェアモデルとしては役に立ちません。

それよりも、エリック・ドーネンバーグが言うように(58ページ)、実際にシステムについての理解が得られる地上300mからの視点を持つようにすべきです。その上で、依存グラフに循環的な依存関係が含まれていないか、誰もリッスンしていない論理チャネルに送られているメッセージはないかといった基本ルールに従うように、モデルに手を入れるのです。

システム・アーキテクチャーという話でも、まったくコントロールなしというわけにはいかないでしょう。観察、モデル抽出、整合性チェックといった方法で完全なコントロールがあり得なくなった状態を補うことこそ、21世紀のアーキテクトが進むべき唯一の道だと思います。