はじめに
第6章では、アーキテクチャ特性を「どのように測るか（計測）」「どのように維持するか（統制）」という運用・継続の観点から整理しました。
では、次に考えるべき問いはこれです。
「そのアーキテクチャ特性は、どこまで適用すべきなのか？」
従来のアーキテクチャでは、システム全体に対して一律に特性を適用するという考え方が一般的でした。たとえば、システム全体で高可用性を確保する、あるいはシステム全体で高スケーラビリティを実現する、といったアプローチです。
しかし、現代のシステムでは事情が変わっています。
PDFでも指摘されているように、かつてはシステム全体でアーキテクチャ特性を考えるのが一般的でしたが、マイクロサービスのような分散アーキテクチャの登場により、そのスコープは小さくなっています。
つまり、すべての機能に同じ特性が必要なわけではないということです。
同じシステムであっても、動画配信には高スケーラビリティ・高パフォーマンスが求められる一方、管理画面にはそこまでの性能は不要です。要求は機能ごとに異なります。
なぜスコープが重要なのか
アーキテクチャ特性をシステム全体に一律に適用すると、過剰設計・コスト増・複雑性の増大を招きます。一方、必要な箇所に適用しなければ、品質が損なわれます。
「どこに適用するか」が、設計の本質となるのです。
本章で扱うこと
この章では、アーキテクチャ特性のスコープを理解するために、以下の2つのテーマを扱います。
① 結合とコナーセンス（7.1）
コンポーネント間の関係性と変更の伝播について整理します。
② アーキテクチャ量子と粒度（7.2）
独立してデプロイ可能な単位、すなわちスコープの最小単位について考えます。
この章の位置づけ
これまでの流れを振り返ると、第3章で「どう分けるか（構造）」、第4章で「なぜそれを選ぶか（特性）」、第5章で「どう見つけるか（抽出）」、第6章で「どう守るか（維持）」を扱ってきました。第7章はその延長として、「どこに適用するか（スコープ）」 を問います。
一言でいえば、第7章は「設計の粒度を決める章」 です。
ここからは、システムを「どの単位で考えるか」という、より実践的で難易度の高い領域に入っていきます。
📖ソフトウェアアーキテクチャの基礎
本書は、O’Reilly Media から出版された『Fundamentals of Software Architecture: An Engineering Approach』 の日本語版です。著者の Mark Richards と Neal Ford が、アーキテクチャを工学的視点から捉え直し、理論と実務を橋渡しする知見をまとめた一冊です。
https://www.oreilly.co.jp/books/9784873119823/
目次（全24章）
1章 イントロダクション
1.1 ソフトウェアアーキテクチャの定義1.2 アーキテクトへの期待
1.2.1 アーキテクチャ決定を下す
1.2.2 アーキテクチャを継続的に分析する
1.2.3 最新のトレンドを把握し続ける
1.2.4 決定の順守を徹底する
1.2.5 さまざまなものに触れ、経験している
1.2.6 事業ドメインの知識を持っている
1.2.7 対人スキルを持ち合わせている
1.2.8 政治を理解し、かじ取りをする
1.3 アーキテクチャと交わるもの
1.3.1 エンジニアリングプラクティス
1.3.2 運用とDevOps
1.3.3 プロセス
1.3.4 データ
1.4 ソフトウェアアーキテクチャの法則
第I部 基礎
2章 アーキテクチャ思考
2.1 アーキテクチャと設計2.2 技術的な幅
2.3 トレードオフを分析する
2.4 ビジネスドライバーを理解する
2.5 アーキテクティングとコーディングのバランスを取る
3章 モジュール性
3.1 定義3.2 モジュール性の計測
3.2.1 凝集度
3.2.2 結合度
3.2.3 抽象度、不安定度、主系列からの距離
3.2.4 主系列からの距離
3.2.5 コナーセンス
3.2.6 結合度とコナーセンスのメトリクスを統合する
3.3 モジュールからコンポーネントへ
4章 アーキテクチャ特性
4.1 アーキテクチャ特性の（部分的な）リスト4.1.1 アーキテクチャの運用特性
4.1.2 アーキテクチャの構造特性
4.1.3 アーキテクチャの横断的特性
4.2 トレードオフと少なくとも最悪でないアーキテクチャ
5章 アーキテクチャ特性を明らかにする
5.1 アーキテクチャ特性をドメインの関心事から捉える5.2 要件からアーキテクチャ特性を抽出する
5.3 事例：シリコンサンドイッチ
5.3.1 明示的な特性
5.3.2 暗黙的な特性
6章 アーキテクチャ特性の計測と統制
6.1 アーキテクチャ特性の計測6.1.1 運用面の計測
6.1.2 構造面の計測
6.1.3 プロセス面の計測
6.2 統制と適応度関数
6.2.1 アーキテクチャ特性の統制
6.2.2 適応度関数
7章 アーキテクチャ特性のスコープ
7.1 結合とコナーセンス7.2 アーキテクチャ量子と粒度
7.2.1 事例：Going、Going、Gone
8章 コンポーネントベース思考
8.1 コンポーネントの分類8.2 アーキテクトの役割
8.2.1 アーキテクチャの分割
8.2.2 事例：シリコンサンドイッチにおける分割
8.3 開発者の役割
8.4 コンポーネントを識別する流れ
8.4.1 初期コンポーネントを識別する
8.4.2 コンポーネントに要件を割り当てる
8.4.3 ロールや責務を分析する
8.4.4 アーキテクチャ特性を分析する
8.4.5 コンポーネントを再構成する
8.5 コンポーネントの粒度
8.6 コンポーネント設計
8.6.1 コンポーネントの発見
8.7 事例：「Going、Going、Gone」におけるコンポーネントの発見
8.8 アーキテクチャ量子再び：モノリシックアーキテクチャと分散アーキテクチャの選択
第II部 アーキテクチャスタイル
9章 基礎
9.1 基礎的なパターン9.1.1 巨大な泥団子
9.1.2 ユニタリーアーキテクチャ
9.1.3 クライアント／サーバー
9.2 モノリシックアーキテクチャと分散アーキテクチャ
9.2.1 誤信1：ネットワークは信頼できる
9.2.2 誤信2：レイテンシーがゼロ
9.2.3 誤信3：帯域幅は無限
9.2.4 誤信4：ネットワークは安全
9.2.5 誤信5：トポロジーは決して変化しない
9.2.6 誤信6：管理者は一人だけ
9.2.7 誤信7：転送コストはゼロ
9.2.8 誤信8：ネットワークは均一
9.2.9 分散コンピューティングにおけるその他の考慮事項
10章 レイヤードアーキテクチャ
10.1 トポロジー10.2 層の分離
10.3 レイヤーの追加
10.4 その他の考慮事項
10.5 このアーキテクチャスタイルを採用する理由
10.6 アーキテクチャ特性の評価
11章 パイプラインアーキテクチャ
11.1 トポロジー11.1.1 パイプ
11.1.2 フィルター
11.2 事例
11.3 アーキテクチャ特性の評価
12章 マイクロカーネルアーキテクチャ
12.1 トポロジー12.1.1 コアシステム
12.1.2 プラグインコンポーネント
12.2 レジストリ
12.3 コントラクト
12.4 事例とユースケース
12.5 アーキテクチャ特性の評価
13章 サービスベースアーキテクチャ
13.1 トポロジー13.2 トポロジーの種類
13.3 サービスの設計と粒度
13.4 データベース分割
13.5 アーキテクチャ例
13.6 アーキテクチャ特性の評価
13.7 このアーキテクチャスタイルがふさわしいとき
14章 イベント駆動アーキテクチャ
14.1 トポロジー14.2 ブローカー
14.3 メディエーター
14.4 非同期の能力
14.5 エラー処理
14.6 データロスの防止
14.7 ブロードキャスト能力
14.8 リクエスト・リプライ
14.9 リクエストベースとイベントベースの間を取る
14.10 ハイブリッドなイベント駆動アーキテクチャ
14.11 アーキテクチャ特性の評価
15章 スペースベースアーキテクチャ
15.1 一般的なトポロジー15.1.1 処理ユニット
15.1.2 仮想ミドルウェア
15.1.3 データポンプ
15.1.4 データライター
15.1.5 データリーダー
15.2 データ衝突
15.3 クラウドとオンプレミス
15.4 レプリケーションキャッシュと分散キャッシュ
15.5 ニアキャッシュの考慮
15.6 実装例
15.6.1 コンサートチケット販売システム
15.6.2 オンラインオークションシステム
15.7 アーキテクチャ特性の評価
16章 オーケストレーション駆動サービス指向アーキテクチャ
16.1 歴史と哲学16.2 トポロジー
16.3 分類
16.3.1 ビジネスサービス
16.3.2 エンタープライズサービス
16.3.3 アプリケーションサービス
16.3.4 インフラストラクチャサービス
16.3.5 オーケストレーションエンジン
16.3.6 メッセージフロー
16.4 再利用...と結合
16.5 アーキテクチャ特性の評価
17章 マイクロサービスアーキテクチャ
17.1 歴史17.2 トポロジー
17.3 分散
17.4 境界づけられたコンテキスト
17.4.1 粒度
17.4.2 データ分離
17.5 API層
17.6 運用面での再利用
17.7 フロントエンド
17.8 通信
17.8.1 コレオグラフィとオーケストレーション
17.8.2 トランザクションとサーガ
17.9 アーキテクチャ特性の評価
17.10 参考文献
18章 適切なアーキテクチャスタイルを選ぶ
18.1 アーキテクチャにおけるトレンドの変遷18.2 判断基準
18.3 モノリスの事例：シリコンサンドイッチ
18.3.1 モジュラーモノリス
18.3.2 マイクロカーネル
18.4 分散型のケーススタディ：Going、Going、Gone
第III部 テクニックとソフトスキル
19章 アーキテクチャ決定
19.1 アーキテクチャ決定に関するアンチパターン19.1.1 資産防御アンチパターン
19.1.2 グラウンドホッグデーアンチパターン
19.1.3 メール駆動アーキテクチャアンチパターン
19.2 アーキテクチャ上重要なもの
19.3 アーキテクチャデシジョンレコード
19.3.1 基本構造
19.3.2 ADRを保存する
19.3.3 ドキュメントとしてのADR
19.3.4 標準のためにADRを用いる
19.3.5 事例
20章 アーキテクチャ上のリスクを分析する
20.1 リスクマトリックス20.2 リスクアセスメント
20.3 リスクストーミング
20.3.1 特定
20.3.2 合意
20.3.3 軽減
20.4 ユーザーストーリーリスク分析
20.5 リスクストーミング例
20.5.1 可用性
20.5.2 弾力性
20.5.3 セキュリティ
21章 アーキテクチャの図解やプレゼンテーション
21.1 図解21.1.1 ツール
21.1.2 標準ダイアグラム：UML、C4、ArchiMate
21.1.3 図解ガイドライン
21.2 プレゼンテーション
21.2.1 時間を操る
21.2.2 段階的な構築
21.2.3 インフォデッキとプレゼンテーション
21.2.4 スライドは物語の半分
21.2.5 不可視化
22章 効果的なチームにする
22.1 チーム境界22.2 アーキテクトのパーソナリティ
22.2.1 コントロールフリーク
22.2.2 アームチェアアーキテクト
22.2.3 効果的なアーキテクト
22.3 どうやって管理する？
22.4 チームの警告サイン
22.5 チェックリストの活用
22.5.1 開発者のコード完成チェックリスト
22.5.2 ユニットテストと機能テストのためのチェックリスト
22.5.3 ソフトウェアリリースのためのチェックリスト
22.6 ガイダンスの提供
22.7 まとめ
23章 交渉とリーダーシップのスキル
23.1 交渉とファシリテーション23.1.1 ビジネスステークホルダーとの交渉
23.1.2 他のアーキテクトとの交渉
23.1.3 開発者との交渉
23.2 リーダーとしてのソフトウェアアーキテクト
23.2.1 アーキテクチャの4つのC
23.2.2 プラグマティックでありながらもビジョナリーであること
23.2.3 手本を示してチームをリードする
23.3 開発チームに溶け込む
23.4 まとめ
24章 キャリアパスを開く
24.1 20分ルール24.2 パーソナルレーダーの開発
24.2.1 ThoughtWorksテクノロジーレーダー
24.2.2 オープンソースのビジュアライゼーションビット
24.3 ソーシャルメディアの使用
24.4 別れの挨拶
付録A 自己評価のためのチェックリスト
参考文献
訳者あとがき
索引
関連書籍
7.1 結合とコナーセンス
まず取り上げるのが「結合とコナーセンス」です。
アーキテクチャ特性のスコープを考えるうえで、最も重要な概念の一つが結合（Coupling）とコナーセンス（Connascence）です。
コナーセンスには、静的コナーセンスと動的コナーセンスの2種類があり、さらに同期・非同期という通信の観点が加わります。これらは、設計の質を左右する本質的な概念です。
以下がブラッシュアップした文章です。
結合だけでは足りない
これまでの設計では、求心性結合（Afferent Coupling）や遠心性結合（Efferent Coupling）といった「依存関係の数」によって構造を評価することが一般的でした。
しかし本書では、コードレベルの結合メトリクスはアーキテクチャ分析としては細かすぎると指摘されています。
重要なのは「依存の数」ではなく、「変更がどのように伝わるか」です。
コナーセンスとは
コナーセンスとは、あるコンポーネントの変更が別のコンポーネントの変更を必要とする関係のことです。一言でいえば、「変更の連鎖」を表す概念です。
◇コナーセンスが強い状態（密結合）
サービスAとサービスBが同じクラス定義を共有している場合、クラスに変更が生じると両方の修正が必要になります。これは強いコナーセンス、すなわち密結合の状態です。
◇コナーセンスが弱い状態（疎結合）
APIを介してやり取りし、契約のみを共有している場合、内部の変更が他のサービスに影響を与えません。これが弱いコナーセンス、すなわち疎結合の状態です。
コナーセンスの種類
PDFでは、コナーセンスを大きく静的と動的の2種類に分類しています。
◇静的コナーセンス
構造に依存する結合です。同じクラス定義・同じ型・同じ名前を共有する場合が該当し、コンパイル時に検出できます。一方で、変更が生じた際に広範囲へ影響が及ぶという問題があります。
◇動的コナーセンス
実行時の振る舞いに依存する結合です。呼び出し順序・タイミング・同期処理などが該当し、実行してみなければ問題が顕在化しません。分散システムにおいて特に重要な概念です。
◇同期と非同期
動的コナーセンスは、さらに同期と非同期に分けて考えることができます。
-
同期コナーセンスは、呼び出し元が応答を待つ構造であるため依存が強く、スケーラビリティの低下や障害の伝播といった問題につながります。
-
非同期コナーセンスは、メッセージベースの通信により呼び出し元が待機しない構造です。PDFでも指摘されているように、非同期メッセージングはより柔軟なアーキテクチャを生み出します。スケーラビリティと柔軟性の向上が主なメリットです。
重要な設計原則
コナーセンスは弱くすることが基本方針です。特に重要なのは、距離が離れるほど弱くするという考え方です。
同一モジュール内であれば強いコナーセンスも許容できますが、サービス間では弱くすべきです。分散システムになるほど、変更の波及による影響が大きくなるためです。
実務での判断基準
避けるべきパターンとして、クラスの共有・DBの共有・同期呼び出しの多用が挙げられます。いずれも強いコナーセンスを生む設計です。
推奨されるパターンは、API契約・非同期メッセージング・データの分離です。これらにより、弱いコナーセンスを実現できます。
図で読み解く：ECサイトを例に
図の左から右への流れに沿って、ECサイトを例に考えてみましょう。
結合の強さ（左の矢印）
注文サービスと在庫サービスが同じDBを共有している状態は、「内容」レベルの結合です。これは最も強い結合であり、一方の変更がもう一方に直接影響します。
静的コナーセンス（上の水色ライン）
注文サービスと決済サービスが同じ Order クラスの型定義を共有している場合、これは「型」の静的コナーセンスです。Order クラスに変更が生じると、両サービスの修正が必要になります。コンパイル時に検出できる分、まだ対処しやすい状態です。
動的コナーセンス（下の緑ライン）
オークション終了時にAuctionサービスがPaymentサービスを同期的に呼び出す設計は、「タイミング」の動的コナーセンスです。Paymentサービスが500ミリ秒に1回しか処理できない制約がある場合、呼び出しがタイムアウトするリスクが生じます。
量子（同期 / 非同期）
この問題を解消するために、AuctionサービスとPaymentサービスの間にメッセージキューを挟み、非同期通信に切り替えます。これにより両者は独立した量子として機能し、コナーセンスが弱まります。
このように図7-1は、結合の強さ → コナーセンスの種類 → 量子の設計という設計判断の流れを一枚で表しています。左から右に向かうほど抽象度が上がり、右端の「量子」が最終的な設計の単位となります。
まとめ（7.1）
- 結合は「依存の数」、コナーセンスは「変更の連鎖」を表す
- コナーセンスには静的（構造依存）と動的（実行時依存）の2種類がある
- 非同期通信はコナーセンスを弱める有効な手段である
- コンポーネント間の距離が遠いほど、疎結合を意識した設計が求められる
良いアーキテクチャとは、変更の影響範囲を最小化することです。設計とは、変更の波及をコントロールする営みといえます。
7.2 アーキテクチャ量子と粒度
前節では、結合とコナーセンスを通して「変更がどのように伝播するか」を見てきました。では次の問いに移ります。
「どの単位でシステムを分割すべきか？」
ここで登場するのが、アーキテクチャ量子（Architecture Quantum）という概念です。
アーキテクチャ量子とは
本書では、
アーキテクチャ量子を「高い機能的凝集を持ち、他から独立してデプロイ可能な最小単位」
と定義しています。
一言でいえば、「一緒に動き、一緒にデプロイされる単位」です。
具体的には、次の性質を持ちます。
- 単一の責務を持つ
- 内部は強くまとまっている（高凝集）
- 外部とは疎結合である
- 単独で変更・デプロイできる
なぜ重要なのか
従来はシステム全体を単位として設計を考えていました。しかし現代の分散アーキテクチャでは、アーキテクチャ特性のスコープは小さくなっており、「どの粒度で分割するか」が設計の核心となっています。
量子ごとに必要な特性を持たせることで、過剰設計を避けつつ、必要な箇所に必要な品質を確保できます。
粒度の考え方
ECシステム全体を一つの単位として扱うような場合、一部の変更でも全体のデプロイが必要になり、スケーラビリティが低く、障害の影響範囲も広くなります。
1機能を1サービスとして細かく分割しすぎると、サービス間の通信が増加し、複雑性と運用コストが膨らみます。
適切な粒度
注文・決済・在庫のように、ビジネス上の意味のある単位で分割することで、それぞれが独立してスケールし、独立してデプロイでき、障害の影響範囲を限定できます。これがアーキテクチャ量子の実践的なイメージです。
粒度のトレードオフ
粒度の選択には必ずトレードオフが伴います。
粒度が粗い場合、シンプルで通信も少なくなる一方、柔軟性が低くスケールしにくい面があります。粒度が細かい場合、柔軟でスケールしやすい反面、複雑性が増し通信コストも上がります。
どちらが正解かではなく、システムの要求に応じてバランスを取ることが求められます。
コナーセンスとの関係
7.1で扱ったコナーセンスの概念は、分割の判断基準としてそのまま活用できます。
コナーセンスが強いもの（変更の連鎖が生じるもの）は同じ量子に含め、コナーセンスが弱いものは別の量子として分離するというのが、分割の基本的な考え方です。
分割の判断基準
PDFが示す重要なポイントとして、量子はデプロイの単位であり実行の単位ではないこと、技術的なレイヤーではなく機能・ビジネスに基づいて定義されることが挙げられます。
よくある失敗パターン
Controller・Service・Repositoryのような技術レイヤーで分割すると、ビジネス上の変更が複数の量子にまたがりやすくなります。また、細かくしすぎることで運用が破綻するマイクロサービス地獄や、逆に粗すぎてモノリスと変わらない状態も、よく見られる失敗です。
まとめ（7.2）
- アーキテクチャ量子は、独立してデプロイ可能な最小の機能単位である
- 高凝集・低結合が設計の基本方針となる
- 粒度の選択にはトレードオフが伴い、ビジネスの文脈に基づいて判断する
- コナーセンスが分割の判断基準として機能する
良い分割とは、「一緒に変わるものを一緒にすること」です。分割とは突き詰めれば、変更とデプロイの単位を決める行為に他なりません。
まとめ
第7章では、アーキテクチャ特性を「どの範囲（スコープ）に適用するか」という観点から整理しました。本章のポイントを振り返ります。
- 結合とコナーセンス（7.1）
結合は「依存の数」を表す指標であり、コナーセンスは「変更の連鎖」を表す概念です。あるコンポーネントの変更が他のコンポーネントの変更を必要とするとき、それらはコナーセンスしているといいます。
コナーセンスには、構造的な依存を表す静的コナーセンスと、実行時の依存を表す動的コナーセンスの2種類があります。
特に重要な原則は、距離が離れるほどコナーセンスを弱くすべきという点です。同一モジュール内であれば強いコナーセンスも許容できますが、サービス間では弱くすることが求められます。分散システムにおいては、この原則が設計の質を大きく左右します。
- アーキテクチャ量子（7.2）
アーキテクチャ量子とは、高い機能的凝集を持ち、他から独立してデプロイ可能な最小単位です。一緒に変わるものをひとつの量子にまとめ、他とは疎結合にすることが基本方針となります。
- 粒度（Granularity）
粒度が粗ければシンプルで通信コストも低い一方、柔軟性に欠けます。粒度が細かければ柔軟でスケールしやすい一方、複雑性と運用コストが増します。粒度の選択は常にトレードオフであり、ビジネスの文脈と変更の実態に基づいて判断することが重要です。
- 分割の判断基準
コナーセンスが強いもの、すなわち変更の連鎖が生じるものは同じ量子に含め、コナーセンスが弱いものは分離するというのが、分割の基本ルールです。技術的なレイヤーではなく、ビジネスと変更の観点から分割を判断することが求められます。
終わりに
第6章では「アーキテクチャをどう維持するか」を扱いましたが、第7章ではさらに踏み込み、「どの単位でアーキテクチャを考えるべきか」という設計の核心に触れました。
ここで見えてきたのは、アーキテクチャ設計とは構造を作ることではなく、「変更の影響範囲をコントロールすること」であるという視点です。
同じ機能であっても、一緒に変更されるのか、独立して変更されるのかによって、最適な分割は変わります。アーキテクトとは「どう分けるかを考える人」ではなく、「どこまで影響が広がるかを設計する人」といえるかもしれません。
良いアーキテクチャとは、機能で分けるものではなく、変化の境界で分けるものです。
第7章までで、構造（第3章）・特性（第4章）・抽出（第5章）・維持（第6章）・スコープ（第7章）という、アーキテクチャ設計の実践的な基盤が一通り揃いました。
次章（第8章）では、コンポーネントベース思考（Component-Based Thinking）をテーマに、実際にどう分割するか、コンポーネントをどう設計するかという、より具体的な設計手法に踏み込んでいきます。理論から実装レベルの設計へと、議論の焦点が移っていきます。