C4モデル (Japanese Edition)

第11章 基礎を超えて

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

この章では、C4モデルに関連するより高度なトピックについて取り上げる。抽象化や図の種類から、マイクロサービスやメッセージ駆動型アーキテクチャを図式化するための具体的な推奨事項に至るまで、幅広く扱う。まずは、C4モデルの4つのレベルと、それらが存在する理由について詳しく見ていくことから始めよう。

モデルとコードのギャップ

第3章から第6章では、C4モデルを構成する静的構造図の種類を紹介し、各章でその特定の図種を使用することを推奨するかどうかについての指針を示した。C4モデルを初めて導入するチームに対する私の一般的な指針は、最上位の2つのレベル、すなわちシステムコンテキスト図とコンテナ図に焦点を当てることだ。

これにはいくつかの理由がある。第一に、システムコンテキスト図とコンテナ図は、ほとんどの場合、比較的短時間で作成できるからだ。第二に、それらの図を最新の状態に保つために必要な労力である。C4モデルの階層的な性質上、各図の変更頻度はそれぞれ異なる。

• システムコンテキスト図： ほとんどの場合、システムコンテキスト図の変化は極めて緩やかだ。これは、ソフトウェアシステムが動作する環境と、その環境内のソフトウェアシステム間の統合ポイントを記述するものであり、これらは定期的に変化する傾向にない。

• コンテナ図： 多数の小さなC4コンテナ（例：マイクロサービス、サーバーレス関数）で構成されるソフトウェアシステムを構築している場合を除き、コンテナ図も比較的ゆっくりと変化する。

• コンポーネント図: 活発に開発が進められているソフトウェアシステムの場合、チームがコードを追加・除去したり、新しい構成要素を導入したり、既存構成要素の境界を変更するためにリファクタリングを行ったりするにつれて、コンポーネント図は頻繁に変化する可能性が高い。

• コード図： コードベースが活発に開発されている場合、コード図はバージョン管理へのコミットごとに変更される可能性がある。

これらはすべて、コードからリバースエンジニアリングするのではなく、ソフトウェアアーキテクチャ図を手作業で作成していることを前提としている。後者も確かに可能だが、セットアップにはある程度の工数が必要となる。

したがって、C4モデルの上位2つのレベルに焦点を当てるという私の推奨事項は、いくつかの質問を招きがちだ：

• ほとんどのエンジニアリングチームにはシステムコンテキスト図とコンテナ図のみの使用を推奨しているのに、なぜC4モデルは4種類の静的構造図を定義しているのか。

• なぜC4モデルは「C2+2モデル」のような名前ではなく、「C4モデル」と名前付けられているのか。

• C4モデルの最初の2つのレベルを使用するよう推奨していることは、その基礎となる抽象化が時代遅れであり、見直しが必要であることを示唆しているのか。

これらの質問に答えるには、一歩引いて、C4モデルが解決しようとしている問題を見直す必要がある。世界中の何百ものエンジニアリングチームと接してきた私の経験に基づけば、概して、エンジニアリングチームの大半は、自社のソフトウェアの動作を説明する図を作成していないか、あるいは第1章で提示したような図を作成しているかのどちらかだ。

あるエンジニアリングチームのソフトウェアアーキテクチャ・図解能力をランク付けするとしよう。図すら作成していない第1のコホートをレベル1とし、 ...