C4モデルの勉強

kyoh86

入口は https://c4model.com/ ここ。
導入にはInfoQの記事を読むと良いよ、と書いてあるので https://www.infoq.com/jp/articles/C4-architecture-model/ を読む。

アジャイルで発信者の意図せずドキュメントを軽視する流れができたらしい
- アジャイル系の本を読んだ感想ではどれも「ドキュメントとコミュニケーション大事」ってことだったけど、僕も現場ではドキュメンテーションができてないので実態にはあってる。
- 実態が個人的な怠惰に依るものじゃなかったのは安心。

kyoh86

図を書くって難しい
- UMLも決定打にはなってない
- どっちみち箱やら線やら並べてぐちゃぐちゃの難解なものができあがる
- 💭 おっしゃるとおり。
コミュニケーションのための何かなのに本質が失われてる
C4モデルは地図みたいなもの
- 地図みたいにZoom outしたりZoom inしたりするのが大事
C4モデルはその詳細度で分かれた4つのレイヤーを持つ
- コンテクスト
  - 最も広い。システムと外の世界との接点にフォーカスする
  - ユーザー、関連するシステムなど
- コンテナ: システムの中身を分解したやつ
  - アプリケーション、データストア、マイクロサービスなど
- コンポーネント: コンテナの中身を見せるやつ
  - コードベースの中の実際の抽象的な概念にふれる。
  - 💭 パッケージとかモジュールとかが見えてくる感じ？
- コード
  - クラス図など
  - コードから生成するのがおすすめ
- 💭 コンテナとコンポーネントの境目が微妙だなぁ。

kyoh86

表記法
- C4は表記法を定めない。
  - ペンと紙でも良い。
  - UMLでもいい。
- ただし
  - 要素には名前と種類（ex: "Person", "Software System" "Container"...）を必ず書く。
  - 適切であれば技術選択（ex: Java）も書く
  - 説明テキストをちゃんと書く。ここが肝で、図の曖昧さを取り除く重要なファクター。
図には凡例とタイトルをつけろ
- その線はどういう意味か、その箱はどういう意味か、をちゃんと書け
- その図全体がどのスコープかが一貫してわかるタイトルをつけろ

kyoh86

表記法を定めない、というが、こういうのを描きやすいツールというのはあまり多くない。
（変に流行り廃りのあるデザインツール（Figmaなど）を使う気も起きない）
DSLを使うのもどうなんだろうと思いつつ、structurizrを使うか…。
https://www.structurizr.com/

kyoh86

structurizrは、VSCodeで拡張を頑張ってる人がいる。
LSPもついてる。
ただ、最近バージョンをメジャーアップデートしてV3にした、ということで未だ不安定らしい。

kyoh86

💭 Java製かぁ…

kyoh86

導入のInfoQは読み終わったので本編を読む
https://c4model.com/

kyoh86

💭 掲載されてるこの図がC4のレイヤーの説明としてはひとまず直感的でいい。
https://c4model.com/img/c4-overview.png

kyoh86

The C4 model is an "abstraction-first" approach

💭 なるほど、レイヤーが分かれてるだけじゃなくて「下（具体）から考えるな」ってことも言ってる。ただしそう。

kyoh86

抽象化を重要視することでソフトウェアの図解を簡単にしよう、という営み
全レイヤーの図を書く必要はない。ContextとContainerだけでも多くのチームには価値をもたらす。

kyoh86

💭 InfoQの内容ちょっと古い？

kyoh86

概念

C4に登場する主要な概念も4つ。

Person: システムを使う人。
Software System

外部に価値を届ける最上位構造。
自分で作るものも、外部で接するシステムも含む概念。
多くの場合は「一つの開発チーム」が作ってるもの

Container (applications and data stores)

Dockerは関係ないぞ
本質は「コードが実行されるもの、データがストアされるもの」
それぞれのコンテナは別々にデプロイ、実行できて、ほとんどの場合プロセスが独立している
色々ある。たとえば…
- サーバーサイドのAPI
- サーバーサイドのWEBアプリ（Rails、Node.JS、Tomcat、...）
- クライアントサイドのWEBアプリ（Angular, React, ...）
- デスクトップアプリ
- データベース
- サーバーサイドのStandaloneなCLI（バッチなど）
- モバイルアプリ
- コンテンツストア（S3など）

コンポーネント

1つのI/Fに紐づく、実装するコード群。
どういうパッケージングがされるか、とは独立して直交する区別。
- ※ただし、クラスベースの考え方に依った表現ではあるので注意が必要そう。
- GoのPackageは「I/Fを提供するもの」であると同時に「パッケージングされる単位」でもある。
  - GoのPackageがコンポーネントに相当するかどうかは、 ものによる だろう。
- C4におけるコンポーネントは、個別にデプロイできない

kyoh86

C4の中核をなす図

先の概念の階層を表現するのにContext、Container、Componentの図を使う。
Code図はオプショナル。

kyoh86

Level1: システムコンテキスト図

図を書き始めるにはここからがおすすめ
立ち戻って書き直すにも良い
自身のSoftware Systemを真ん中の箱において、関係するユーザーや関連するシステムを周りに置く。
詳細にこだわらず、採用した技術や相互作用の内容、方法は一旦捨て置く。
人（誰なのか、役割、ペルソナなど）とSoftware Systemsにフォーカスする。

図の概略

ほぼ引用（訳のみ）:

スコープ: 単一のソフトウェアシステム。

主な要素: スコープ内のソフトウェアシステム。

他の要素:

スコープ内のソフトウェアシステムに直接接続する人（ユーザー、アクター、役割、ペルソナなど）およびソフトウェアシステム（外部依存関係）

通常、これらの他のソフトウェアシステムは、独自のソフトウェアシステムの範囲または境界の外にあり、ユーザーにはそれらの責任または所有権はない。

対象読者: ソフトウェア開発チームの内外を問わず、技術者と非技術者の両方の全員

ほとんどのチームで作るべきもの