複雑なシステムを分解する
細部ではなく、境界と入出力から始める
[システム名]（例：[具体例]）の分解を手伝ってください。順番に：1）まず境界を引く——中にあるもの、外にあるもの；2）入力・出力・維持すべき目標を列挙；3）3〜6 のサブシステムに分け、それぞれの責務と相互のインターフェースを示す；4）ボトルネックや単一障害点はどこか；5）具体的なシナリオを 1 つ流し、私が見落としがちな工程に印をつける。情報が足りない箇所は「不明」と書き、作らないこと。
使い方
まず自分のよく知るシステムで一度試し、それから新しい対象へ。構造の感覚が早く身につく。
向いている場面
- 他人が作ったシステムを引き継ぎ、二時間で調査を始められる心の模型を作りたいとき
- システムが遅くなった、あるいは新しい要件が来たが、変更がどこに響くか説明できないとき
向いていない場面
- 社内システムでモデルに信頼できる情報がなく、もっともらしく構成やコンポーネント名を捏造するとき
- システムが十分小さく十分でコードを読める、あるいは必要な設定値が一つだけ分かればよいとき
例
入力
システム：Kafka クラスタ。プロデューサの書き込みからコンシューマの読み取りまでの主経路をたどる。
得られるもの
境界は「Kafka が永続化と複製を担い、業務の意味は担わない」に引く。サブシステムはネットワーク層、ログストレージ、コントローラ、レプリカ同期、コンシューマグループ調整の五つに分け、それぞれのインターフェースを示す。ボトルネックは通常、単一パーティションの順次追記と ISR 同期で、旧構成の単一障害点はコントローラ（ZooKeeper 依存）。シナリオをたどる際は「acks=all の遅延は最も遅い ISR で決まる」のような見落としやすい箇所を指す。
よくある誤用
- 最初に細部（rebalance プロトコルの動作）を聞く。境界も入出力もないので細部の置き場所がなく、読んでも散らかったままになる
- 出力をそのまま実際の構成図として報告する。よくある設計から補われた、自分のシステムには存在しないコンポーネントが混ざっていることがある
こう変えると効く
- 順序を逆にする。先に具体的なシナリオをたどり、そこから必要なサブシステムを逆算させる。欠けている部品が見つけやすい
- 「流量が十倍になったら最初に壊れるのはどこか、なぜか」と足す。静的な分解が容量の推論になる