ソフトウェアアーキテクチャ可視化のためのC4モデル (2017)
(c4model.com)- C4モデルは、ソフトウェアアーキテクチャ図を作成するための開発者フレンドリーなアプローチであり、複雑な構造を段階的に分けて見られるようにする
- 抽象化は software systems → containers → components → code の順に下り、アーキテクチャを階層的に扱う
- 図も system context → container → component → code の構造に沿って構成される
- 必要に応じて system landscape、dynamic、deployment 図によって、全体構造と実行・配備の観点を補完する
- 特定の記法やツールに縛られない notation independent、tooling independent な方式であり、既存環境に合わせて適用できる
C4モデルの構成
- C4モデルはソフトウェアアーキテクチャを可視化するためのモデルで、作成者は Simon Brown
- 核心は 階層的抽象化 と 階層的ダイアグラム をあわせて使うことにある
ダイアグラムと独立性
- 基本ダイアグラムは、アーキテクチャを異なる深さで見られるように構成されている
- 補助ダイアグラムは、基本階層だけでは不足する観点を補う
- このモデルは notation independent かつ tooling independent であり、特定の記法やツールの選択を強制しない
- 関連資料として、2019年7月の「Agile on the Beach 2019」で収録された Visualising software architecture with the C4 model 動画と The C4 model 資料がある
1件のコメント
Hacker Newsのコメント
アーキテクチャ図の最大の問題は、コードベースとずれてしまう点だと思う
こうした図は自動生成が必要。そうでなければ、いま見ている図がシステムの最新状態を正確に表しているかをチームが知る方法がない
図は特定の視点を示し、ある特徴を強調し、別のものは省略する。同じ対象についても、異なる側面やシナリオを説明する複数の図があり得る。結局、図もテキスト文書と同じように、コードやアプリケーションアーキテクチャと一緒に保守する必要があり、変更管理の定常作業にするしかない
多くのプロジェクトでは、頭の中のモデルと同じ形でコードを構成しておらず、ほとんどすべての言語がこれを解決する手段を提供していない。コードにコメントで印を付けるのも、図、コメント、文書を最新状態に保つのと同じ問題を抱える
現在の状態ではなく目標状態を表す。コードは図に従うべきで、その逆ではない。コードから図を生成することに意味があるのは、ドキュメントのないプロジェクトに新しく参加する人を助ける程度で、その場合でも一度生成した後にノイズを取り除いて整え、その後の基準文書として使うという形になる
高レベル図は素早く作って捨てられるべきで、何を見せるかと同じくらい、何を省略するかも重要
C4が気に入っている。以前は「User -{do their job}-> System-of-Record」のようなコンテキスト図は役に立たないと思っていたが、今はその理由が分かる
複雑なシステムの新しい設計を、拡張チームとC4で進めている。今回、最上位の図を描いているうちに、Web UIのほかに接続が半ば切れている可能性のあるモバイルアプリがあり、オフラインだったりバックエンドが遅かったりするときに特定の結果がまだなければ、一部の動作を優雅にデグレードさせる必要があることに気づいた。これが次の階層では作業キューにつながり、さらにUXにつながって、どのリクエスト完了に無期限に時間がかかり得るのかを明確に言えるようになった。いずれは到達していただろうが、分析がこの問題を正面に置いてくれた。すべては「Remote-User --{Mobile Stuff}--> Backend」という図を描かなければならなかったからだ。ツールは何を使っても構わず、私は例えばdraw.ioで階層ごとにタブを分けて使っている。さらに具体化したら、低い階層は別ファイルに分ける予定
図に形式化された体系は不要だという主張も理解できるが、C4はかなり軽量な方だと思う。私はコードレベルまでは下りない
それでもC4図を出力するstructurizrは、生産性を大きく高めてくれた。1つのモデルから詳細度の異なる複数のビューを生成する方式は、各図が独立して同じ構成要素を何度も定義・再定義しなければならないmermaidやplantumlなどと比べると素晴らしい。ブランチを切り、モデルを修正し、アイデアを発表する流れが、自分にはとてもよく合っていた
C4に厳密には属さない概念を描く方法がなかった。例えば2つのコンポーネントを1つの箱に入れて、現在は1つのサービスとしてデプロイされている事実を表したかったが、不可能だった。それが絶対的に良い設計だという意味ではないが、チームの理解には役立ったはずだ。アーキテクチャを形式的に記述するというアイデアは良いが、図の出力におけるカスタマイズ不足が非常につらかった
アーキテクチャを記述すると、structurizrが図をレンダリングする
できなくはないがかなり面倒で、ボックス間の矢印説明が長くなると自動レイアウトがすぐに崩れる
ソフトウェアアーキテクチャは、実装を導く設計上の意思決定の集合だと見る立場です。
私の経験では、ほとんどのソフトウェアアーキテクトはソフトウェアエンジニアに指針と構造を示します。ところがC4の説明にある「既存コードの地図を複数の詳細レベルで作る」という言い方は、違って聞こえます。コードのダイアグラムをなぜソフトウェアアーキテクチャと呼ぶのか分かりません。それは文字どおりコードレベルであって、どうしてアーキテクチャなのかと思います。プラグ内部の回路図を家の設計図に入れようとするようなものです。「自動化ツールを使うべきだ」というなら、既存のコードベースを関数単位で文書化しようということなのでしょうか。それがソフトウェアを設計し計画するうえでどう役立つのか分かりません。既存ソフトウェアの構造を説明する地図は格好いいかもしれませんが、デザインパターンを語るときにシングルトンの実装を関数ごとの地図として提示したりはしません。シングルトンやリポジトリパターンが必要だと言えば十分です。ソフトウェア設計そのものは確かに存在し、こうした方法も設計としては妥当に見えますが、私の経験上、ソフトウェア設計・実装・アーキテクチャは同じものではなく、同じ人たちが担うものでもありません。これはシステム設計に近いように見え、ソフトウェアアーキテクトはそのシステム設計が良いアーキテクチャ原則に沿うよう助言する役割なのだと思います。細かく言いすぎかもしれません。
開発者が毎回権威者に判断を委ねるのではなく、自分で設計判断を下せるよう情報を与えることは、ソフトウェアアーキテクチャの不可欠な役割だと思います。ただし、アーキテクチャがどこで終わり、開発がどこから始まるかは大きく異なります。アーキテクチャ自体が、アーキテクチャの観点から何が重要かを決めるのだと思います。ある低レベルのアプリケーション詳細が重要だとアーキテクチャが判断すれば、それもアーキテクチャ上の詳細になります。実際、ほとんどの組織でアーキテクチャは少なくともコンポーネント、通信パターン、API、使用技術といった上位設計を統制します。組織によっては個別クラスまで踏み込むこともあります。すべてのクラスではなく、問題ドメインをモデル化するクラス、特にそのモデルが複数プロジェクトの言語として使われたり共有成果物として実装されたりする場合です。C4は、アプリケーションと統合インターフェースの一覧を超えて、より低いレベルの構造までをアーキテクチャ上の関心事と見る組織に適しています。
基本的には、システム内で明確に固有または有用な各レベルごとにダイアグラムを用意するということです。コードレベルのダイアグラムが必要なら、複雑なカスタム作業をしている最中か、実装詳細として残しておけばよい設計を過度に仕様化している可能性が高いです。
現実の不動産建設でも、建築家、エンジニア、現場責任者の役割が異なるのと似ています。アーキテクチャ・設計・実装それぞれでどこに線を引き、どの関心事を扱うべきなのかが気になります。
興味深いものの、特に何かを付け加えているとは見なしにくいです。
高レベルのダイアグラムは良いものですが、見栄えのするビジュアルモデルのWebサイトを読まなくても、すでに作れます。サイトも実質的にそれを認めています。業界にはUML、ArchiMate、SysMLがありますが、多くのチームがはるかに単純な「箱と線」のダイアグラムを選んだというのはまったくその通りです。ところが、なぜUMLクラス図が完全に失敗したのかは無視しているように見えます。誰も好んでいないことは認めつつも、このモデルの4つ目のCであるコードは、結局UMLクラス図です。こういうものは不要です。任意のダイアグラムを明確に描き、矢印にラベルを付ければよいだけです。最初の3つのダイアグラムのほうが、むしろその良い例です。
新しい概念を考えたりブレインストーミングしたりするときも、ツールが足を引っ張らないので大いに役立ちます。今はFreeformを使っていますが、とても単純ながらうまく動きます。オブジェクトを2つ選んでcmdクリック、または右クリックして「add connecting line」を押せば済みます。
ほんの数か月前にも、クラス図、シーケンス図、ユースケースが十分に入ったアーキテクチャ文書をまた仕上げました。
箱が互いに異なるレベルのものを混ぜた状態になりがちです。あるものは抽象的で、あるものは具体的で、あるものは単に恣意的です。そのため、例えばサプライチェーンのようにより大きなアーキテクチャの部品を組み合わせる必要が出ると、実質的に全部やり直すことになります。無駄が多く、全体アーキテクチャを十分明確に見ている人もいないため、さらに別の無駄や品質問題につながります。不思議なことに、多くのエンジニアはより形式的なアプローチに防御的に反応しますが、おそらく即時の利益がないか、大規模アーキテクチャを扱ったことがなく問題が見えていないからだと思います。
ソフトウェア工学がまだ未成熟な分野であることを示しています。
私の場合、25年以上たってもなお、「基本」に近い同じ議論を続けています。これが悪いという意味ではありませんが、進展は遅く、特定の会社やコンソーシアム、商業的利害のせいだけにすることもできません。
誰かがひとつの考えの中で、高い詳細度と高い複雑性、遠くから見た単純さの間を行ったり来たりし続け、何を言おうとしているのか理解しづらかったことがどれほどあるでしょうか。開発者が「このボードに箱と矢印を適当に描けばいい、自分の頭の中では筋が通っているから良いダイアグラムだ」と考えるときにも、同じ問題が起きます。
土木エンジニアでなくても、平面図のようなものはすぐ理解でき、有用だと感じられます。
しかし専門のソフトウェアエンジニアであるにもかかわらず、この例のダイアグラムは手間をかけるほど有用でも情報量が十分でもないように見えます。コードはあまりに多次元的で、2次元の図で近似するのが難しく、うまく機能しません。可能性があるのは、より慣例化されたアーキテクチャ上のコードパターンです。構造化並行性のようなもの、そしてそれよりさらに高いレベルの何かかもしれません。
平面図は文脈が非常に固定されており、範囲も限られています。例えば窓を説明する必要はありません。しかしソフトウェアでは、たいてい「窓」を実際に説明しなければなりません。すべての「窓」や要素が互いに異なるため、単にこれは窓だと言って20回コピーすることはできません。
C4モデルがあまりに恣意的で、過度に仕様化されていると感じるなら、今年初めに代替的な実践方法について書いた: [https://www.ilograph.com/blog/posts/concrete-diagramming-mod...](https://www.ilograph.com/blog/posts/concrete-diagramming-models/）
このモデルは気に入っているし、セキュリティアーキテクチャでUMLを使わなければならなかったこともある。あの分野では、最上位のコンテキストからコードまでの一貫性が核心だからだ
C4モデルの単純さは、一種の強制装置である。隠れたコンテキストやコンポーネントがあれば、モデル内で明らかにならなければならない。これほど単純なものにも抵抗があるなら、隠れた要素がある可能性を示すサインだと考えている。大規模プロジェクトには、実際にそうした要素がたいてい存在する。人々にこのような形で思考を明確にさせると、単に提案して批判する権利を残しておくのではなく、発言やアイデアにコミットすることになり、権限が分散される。これに対しても多くの抵抗が生じうる。ただしこれはモデルの問題ではなく、モデルが人と出会ったときに起きることだ。一貫性が気に入っているので、セキュリティ設計の参考用としてこうした方法を使うと思う
C4は非常に興味深く、ソフトウェアアーキテクチャの特定の問題をうまく扱っていると思う
アーキテクチャの低い層、つまり主にハードウェアとシステムソフトウェアを広い抽象化として扱い、その上のスタックにあるものへ労力を集中させる。今日のクラウドベースでコンテナ化されたスケーラブルなアプローチに、驚くほどよく合っている。関連してArchiMateも良く、重なる部分が多いが、インフラ側によりしっかり足場を置いている。過去にArchiMateに似たダイアグラム手法を使い、システムとデータソースの衝突を減らし、購入してつなぎ込むものが特定のビジネスやユーザーワークフローの要件をどう支えるのかを示すうえで、大きな効果があった。これらがコードベースとずれるという指摘はまったくその通りだ。しかし、複雑なシステムを分析したり、より大きなグループにシステムや計画を伝えたりする必要があるときには、優れたツールになりうる。まとまったドキュメントがまったく存在しないケースは驚くほど多く、数週間座って箱と接続線を描くだけで、前に進めず行き詰まっていた作業がほどけ、単純化されることもある。特に複数のチームが同じ領域で作業している場合はそうだ。C4、ArchiMate、UMLなどは、伝達・分析・記録したい特定の内容を捉えるための、制約のあるダイアグラム言語にすぎない。事前計画や設計ツールとしては、あまり良いものではないと思う。多くの人が巨大なUMLブームの時代に苦労した。コードを1行書く前に、チーフアーキテクト組織がクラス定義に至るまでシステムのあらゆる面を苦痛なほど詳細に敷き詰めるべきだ、という考え方であり、「ダイアグラムからコードを生成すればよい」といった狂気が多くの人を苦しめた。実際のコーディングが始まると、その何千時間もの計画はたいてい無視され、開発者たちは結局やりたいようにやった