マイケル・ナイガードシステムは、相互依存するプログラムから構成されています。プログラムの関係と配置をアーキテクチャーと呼びます。システムのダイアグラムを描くときには、個々のプログラムやサーバーを小さなボックスで表し、矢印で結びます。1つの小さな矢印が、たとえば「HTIP上のSOAP-XMLを使った同期的な要求/応答」を意味します。1つの記号が表す情報としてはかなり多いと言えるでしょう。普通は全部を書くことはとてもできないので、開発部内向けに「HTIP上のXML」と書いたり、外部向けに「SKU照合」と書いたりします。矢印が結ぶプログラムは直接つながっているかのように見えますが、実際はそうではありません。ボックスの間の空白は、実際にはプリント基板と同じで、さまざまなハードウェア/ソフトウェア・コンポーネントによって埋められています。この「基板」には、次のようなものが含まれています。幹線ネットワーク太平洋、大西洋ケーブル探索用トロール船プログラムAとBの間には、いつも4、5台のコンピューターが介在しており、それぞれがパケット交換、トラフィツク分析、ルーティング、脅成分析などのソフトウェアを実行しています。プログラムに橋を架けていくアーキテクトとして、あなたはこれらの「基板」に注意する必要があります。私が見た矢印の中に、「履行」というラベルのついたものがありました。矢印が結ぶ片方のサーバーは私の顧客企業の中にあり、もう片方のサーバーは別の企業の中にありました。この矢印は顧客企業にとっては決定的に重要な意味を持っていましたが、単一のインターフェイスというよりも、ピタゴラスイッチのような連続的な操作でした。メッセージはメッセージブローカーに送られ、そこでファイルにダンプ出力されます。ファイルは、定期的にピックアップされてFTPで送られます。この単一の「インターフェイス」には、20以上のステップが含まれていたのです。矢印が表す静的/動的負荷を理解することはとても大切です。矢印には「HTTP上のSOAP-XMLJと素っ気なく書かれていても、「1個のHTTPリクエストで1つの問い合わせを送ると、1個のHTTPレスポンスで1つの応答が返される。1秒に遅れる要求は100個までで、99.999%までは250m秒以内に応答が返される」というところまで読み込まなければなりません。矢印については、他にも知っておかなければならないことがあります。呼び出し元が、頻繁すぎるくらいに要求を送ってきたときにどうするか。レシーバーは、リクエストを床に落として捨てるか、礼儀正しく処理を拒否するか、がんばってできる限り処理するか。250m秒たっても応答が返ってこないときに、呼び出し元はどうすべきか。再試行すべきか、待ち続けるか、レシーバーがエラーを起こしたと考えてその部分を省略して先に進むか。呼び出し元がプロトコルのバージョン1.0で要求を送り、レシーバーがバージョン1.1で応答を返してくるときにはどうするか。応答がXMLではなくHTMLだったらどうするか。XMLではなくMP3ファイルだったらどうするか。インターフェイスの片方がしばらく姿を消してしまったときにはどうするか。これらの問いに答えることこそが、「基板」を意識した設計のエッセンスです。ソフトウェアアーキテクトが知るべき97のこと当サイトはオライリー・ジャパンによる公式なサイトではありません。個々のエッセイは「CC-by-3.0-US」によってライセンスされています。2プロジェクト・マネジャーが知るべき97のこと。