ソフトウェアアーキテクチャのためのC4モデル入門

アーキテクチャ図のすべてを考え直すきっかけになったホワイトボードセッションを今でも覚えています。新しい開発者をオンボーディングしていて、eコマースプラットフォームを説明するために45分かけてボックスと矢印を描きました。最後には、彼女は始める前より混乱していました。図にはすべてが含まれていました——マイクロサービス、データベース、メッセージキュー、外部API——すべてが一貫性のない表記法で、明確な階層なく詰め込まれていました。

その夜、Simon BrownのC4モデルに出会い、「なぜ思いつかなかったんだ？」という瞬間でした。アイデアは見かけ上シンプルです：すべてを1つの図に詰め込む代わりに、異なるズームレベルで複数の図を作成します。Google マップのように、ズームアウトした全体像から始め、段階的にズームインして詳細を見ます。

C4の4つのレベル

「C4」は4つの抽象化レベルを表し、それぞれが異なる質問に答えます：

レベル1：システムコンテキスト

30,000フィートのビューです。システム全体が1つのボックスで、以下を示します：

• 誰がシステムを使うか（人やロール）
• どの外部システムと統合しているか

これだけです。内部の詳細なし、技術選択なし、データベースなし。初めてプラットフォームのシステムコンテキスト図を描いたとき、1枚のスライドに収まりました。CEOが理解できました。私のアーキテクチャ図でそれが起きたのは初めてでした。

レベル2：コンテナ図

1レベルズームインします。C4用語の「コンテナ」はDockerコンテナではなく、コードを実行またはデータを保存するデプロイ可能なユニットです：Webアプリ、モバイルアプリ、バックエンドサービス、データベース、メッセージキュー、ファイルストレージ。

レベル3：コンポーネント図

単一のコンテナ内にズームインします。コンポーネントはそのコンテナ内の主要な構造的ビルディングブロック——サービス、リポジトリ、コントローラー、モジュールなどです。

レベル4：コード図

最も深いレベルで、実際のコード要素——クラス、インターフェース、関数を示します。Simon Brown自身がこのレベルはオプションで、多くの場合コードから自動生成されると述べています。

なぜC4がチームにフィットしたか

C4以前、アーキテクチャドキュメントは混乱していました。C4モデルは実際に機能するフレームワークを与えてくれました：

覚えられるほどシンプル

4つのレベル。それだけです。14種類のUML図を覚える必要はありません。

異なるオーディエンス、異なる図

CEOはシステムコンテキスト図を見ます。アーキテクトはコンテナ図を議論します。開発者はコンポーネント図で作業します。

最新の状態を維持

C4図は比較的シンプルなので、更新が苦痛ではありません。

ツール非依存

C4モデルは概念についてであり、表記法についてではないので、どのツールでも機能します。

よくある間違い

間違い1：早すぎる段階で詳細を見せすぎる

最初のコンテナ図には47個のボックスがありました。正確でしたが役に立ちませんでした。

間違い2：リレーションシップを忘れる

ボックスがあって矢印のない図はただのインベントリです。

間違い3：変更後に更新しない

最良の図も2年前のシステムを記述していれば無意味です。

間違い4：表記法を過剰設計する

見た目ではなく内容に集中しましょう。

はじめかた

1. システムコンテキストから始める。30分かけてシステムを描きましょう。
2. コンテナ図を1つ追加。最も複雑なシステムを分解しましょう。
3. ここで一旦止める。図がその価値を証明してから、さらに時間を投資しましょう。
4. コラボレーティブにする。図をチームと共有しましょう。

まとめ

C4モデルはコンセプトとしては革命的ではありません。Simon Brownが素晴らしかったのは、これらのアイデアをシンプルで覚えやすく、実際に使われるフレームワークにパッケージしたことです。

アーキテクチャドキュメントが古いVisioファイルとホワイトボードの写真の寄せ集めなら、C4を試してみてください。システムコンテキスト図1つから始めましょう。よく考えられた1枚の図がもたらす明確さに驚くかもしれません。

これはアーキテクチャドキュメントシリーズの一部です。次回：AIがアーキテクチャを自動発見する方法とドキュメントが思っている以上に重要な理由。