はじめに
前章（第8章）では、コンポーネント設計をテーマに、コンポーネントの識別・粒度・ワークフロー中心設計・アーキテクチャ量子について整理しました。特に重要だったのは「良い設計とは、変更の境界を適切に分割すること」という考え方です。
本章からはいよいよ、本書の大きなテーマの一つであるアーキテクチャスタイルに入っていきます。
アーキテクチャスタイルとは
本書では、アーキテクチャスタイルをシステム全体の構造的な特性や、コンポーネント同士の関係性を定義するものとして説明しています。
レイヤードアーキテクチャ・パイプラインアーキテクチャ・イベント駆動・マイクロサービスなどはすべてアーキテクチャスタイルの例です。
ここで重要なのは、「どのスタイルにもトレードオフがある」という点です。モノリスはシンプルである一方スケールしづらく、分散は柔軟である一方複雑になります。どのようなアーキテクチャにも「得るもの」と「失うもの」が存在します。
本章で扱う内容
第8章までは「どう分割するか」「どう設計するか」という構造的な問いを中心に学んできました。しかし実際のシステムでは、ネットワーク障害・レイテンシ・データ整合性・分散トランザクション・可観測性といった、分散システム特有の問題が必ず発生します。
本章が一貫して伝えているのは、分散システムはモノリスよりも難しい問題を持ち込むという現実です。「分散＝モダン」という単純な図式は成り立ちません。
本章では「モノリスと分散アーキテクチャ」という現代アーキテクチャの中心テーマを扱いながら、分散アーキテクチャに潜む誤解・落とし穴・複雑性について整理していきます。
前半では、アーキテクチャの基礎パターンとして、巨大な泥団子・ユニタリーアーキテクチャ・クライアント／サーバー・3層アーキテクチャを振り返ります。
後半では、本書が特に重要視する**「分散コンピューティングの8つの誤信」**を扱います。「ネットワークは信頼できる」「レイテンシはゼロ」「帯域幅は無限」「ネットワークは安全」といった思い込みが、実際のシステムでいかに深刻な問題を引き起こすかを見ていきます。
本当に重要なのは「なぜ分散化するのか」「その複雑性を受け入れる価値があるのか」を問い続けることです。第9章は、理想的な設計から一歩進み、**「現実世界でアーキテクチャがどのように機能し、どのように限界を迎えるのか」**を学ぶ章といえます。
ここからは、ネットワーク・分散・可用性・整合性・運用といった、現場のソフトウェアアーキテクチャの核心へと踏み込んでいきます。
📖ソフトウェアアーキテクチャの基礎
本書は、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 自己評価のためのチェックリスト
参考文献
訳者あとがき
索引
関連書籍
9.1 基礎的なパターン
現代では、マイクロサービス・Kubernetes・サービスメッシュ・イベント駆動などが注目されがちですが、これらはいずれも過去のアーキテクチャの延長線上に存在しています。「なぜ今のアーキテクチャが生まれたのか」を理解するには、古典的な構造を理解することが不可欠です。
本節では、巨大な泥団子・ユニタリーアーキテクチャ・クライアント／サーバーといった基礎パターンを通して、アーキテクチャ進化の流れを整理していきます。
9.1.1 巨大な泥団子（Big Ball of Mud）
本書で最初に登場するのが「巨大な泥団子（Big Ball of Mud）」です。名称のインパクトは強いですが、これは非常に現実的なアーキテクチャパターンです。
一言でいえば、「秩序なく成長したシステム」です。どこからでもアクセス可能で責務が曖昧、依存関係が複雑で構造上のルールが存在しない、いわゆるスパゲッティ構造です。ControllerからSQLを直接実行したり、CommonUtils・GlobalHelperのような責務の曖昧な共通クラスが乱立したり、OrderとUserとPaymentが互いに依存し合う循環依存が生じたりすることが典型例です。
本書では、巨大な泥団子は最初から意図して作られるわけではないと説明されています。短納期・その場しのぎの改修・一時対応・設計不足が積み重なった結果として生まれるものです。
この状態ではコナーセンスが極端に強くなり、変更の影響範囲が不明確になります。結果として保守不能・テスト困難・デプロイへの恐怖という状況に陥ります。本書が警告するように、良い設計は意識しなければ自然には生まれません。多くのシステムは、意識的な設計なしには巨大な泥団子へと向かっていきます。
9.1.2 ユニタリーアーキテクチャ
ユニタリーアーキテクチャとは、一つのアプリ・一つのデプロイ単位・一つのDB・一つのプロセスとして完結する構造を指します。モノリシックアーキテクチャに近い考え方です。
メリットとして、構造がシンプルで理解・デバッグがしやすいこと、メモリ内呼び出しによりネットワークを介さず高速であること、ローカル実行が容易で開発しやすい点が挙げられます。一方でデメリットとして、巨大化しやすいこと、一部に負荷が集中しても全体をスケールする必要があること、障害の影響範囲が大きくなりやすいことがあります。
重要なのは、本書がユニタリーを「悪い設計」とは述べていない点です。小規模から中規模のシステムでは非常に合理的な選択肢であり、「分散＝常に正解」ではありません。
9.1.3 クライアント／サーバー
クライアント／サーバーアーキテクチャは、現在でも最も基本的な構造です。処理をクライアントとサーバーに役割分担するこの構造は、現代のWebシステムにおいてもブラウザとAPIサーバーという形で本質的には変わっていません。
アーキテクチャの発展を辿ると、まずデスクトップアプリがデータベースに直接接続する形がありましたが、クライアントの増加によるDB負荷の増大・セキュリティの脆弱さ・強い結合という問題がありました。その後、ブラウザとWebサーバーがHTTPで通信する現在主流の構造が登場し、クライアントの軽量化・配布の容易さ・集中管理という利点をもたらしました。
さらに発展したのが3層アーキテクチャです。Presentation（UI・入力受付）・Business（業務ロジック）・Database（永続化）という構造で責務を分離したこの形は、後のレイヤードアーキテクチャ・サービスベース・マイクロサービスの原型となっています。
9.1のまとめ
本節で見た流れは、巨大な泥団子からユニタリー、クライアント／サーバー、そして3層アーキテクチャへという進化の歴史です。
- 巨大な泥団子は、意識的な設計なしに自然に向かう秩序のない構造である
- ユニタリーアーキテクチャは、シンプルさを活かせる場面では合理的な選択である
- クライアント／サーバーは役割分離の基本であり、現代アーキテクチャの出発点である
- 3層アーキテクチャは責務分離を実現し、現代の多くのスタイルの原型となっている
現代のアーキテクチャは、過去の構造が抱えていた問題を解決するために進化してきたものです。
9.2 モノリシックアーキテクチャと分散アーキテクチャ
前節では、巨大な泥団子・ユニタリーアーキテクチャ・クライアント／サーバー・3層アーキテクチャといった基礎的な構造を見てきました。現代では多くのシステムがマイクロサービス・Kubernetes・イベント駆動・クラウドネイティブといった分散アーキテクチャへと向かっています。
しかし本書では、分散アーキテクチャはモノリシックアーキテクチャよりも本質的に複雑であると強調されています。モノリスでは同一プロセス・同一メモリ内での処理が中心ですが、分散ではネットワーク越しの通信が前提となります。つまり、モノリスには存在しなかった「ネットワーク問題」が設計の核心に入り込んできます。
本節では、分散システムで繰り返し問題となる**「分散コンピューティングの8つの誤信」**を見ていきます。これらはいずれも「ネットワークはこう動くはず」という思い込みであり、現実のシステムではその前提がほぼ成立しません。
9.2.1 誤信1：ネットワークは信頼できる
ネットワーク通信は必ず成功するという前提は誤りです。タイムアウト・パケットロス・DNS障害・ロードバランサー障害・一時的な切断は、分散システムでは日常的に発生します。
モノリスの関数呼び出しはほぼ失敗しませんが、サービス間のHTTP通信はネットワーク障害の影響を直接受けます。たとえば決済APIの呼び出しが失敗した場合、リトライすべきか、ロールバックすべきか、補償トランザクションが必要か、ユーザーへどのように伝えるかという問いが一気に発生します。本書では、分散システムでは失敗を前提にした設計が必要と説明されています。
9.2.2 誤信2：レイテンシーはゼロ
通信は一瞬で完了するという前提も誤りです。実際には数ミリ秒から数百ミリ秒、場合によっては数秒のレイテンシーが発生します。モノリスのメモリ内呼び出しは極めて高速ですが、REST・gRPC・メッセージキューを介した通信はそれに比べて遅くなります。
特に問題となるのがChatty APIと呼ばれるパターンです。AからBへ、BからCへと連鎖的に呼び出しが続く設計では、レイテンシーが積み重なり、UXの悪化・タイムアウト・可用性の低下につながります。本書ではネットワーク越しの呼び出しは「高価」であると説明されています。
9.2.3 誤信3：帯域幅は無限
大量のデータを送っても問題ないという前提も成立しません。帯域制限・転送量の増大・API肥大化は現実的な問題です。数万件のレコードを含む巨大なJSONをそのまま送信したり、一覧取得のたびに1件ずつ追加APIを呼び出すN+1問題が発生したりすると、通信がボトルネックになります。分散システムでは、やり取りするデータ量を意識した設計が不可欠です。
9.2.4 誤信4：ネットワークは安全
社内通信だから安全という前提も危険です。中間者攻撃・不正アクセス・トークン漏洩・内部侵害は実際に起こります。本書でも指摘されているように、モノリシックから分散アーキテクチャへ移行すると、脅威や攻撃の表面積は飛躍的に増加します。TLS・ゼロトラスト・認証認可・mTLSといった対策が必要であり、分散システムでは内部通信も信頼しないという設計思想が求められます。
9.2.5 誤信5：トポロジーは決して変化しない
サーバー構成は固定されているという前提も現代では通用しません。Auto Scaling・Kubernetes・Podの再配置・Serverlessといった仕組みにより、インフラの構成は常に変化します。そのためService Discoveryや動的ルーティングへの対応が必要となります。
9.2.6 誤信6：管理者は一人だけ
すべてを同じチームが管理しているという前提も現実と乖離しています。大規模な組織では数十人のネットワーク管理者が存在することもあり、チームの分割・クラウドの管理・SaaSの利用によって管理の境界は複雑になります。権限・責任・SLAの調整が必要となるこの問題は、分散アーキテクチャ特有の運用上の複雑性を示しています。
9.2.7 誤信7：転送コストはゼロ
通信は無料という前提も誤りです。クラウド環境ではデータ転送料・CDN費用・クロスAZ通信・クロスリージョン通信といったコストが発生します。大量の通信はそのままクラウドの請求額に反映されます。本書ではこの誤信をレイテンシーと混同しやすいと指摘しており、ここでいう転送コストはレイテンシーではなく、通信に伴う実際の費用面のコストを指しています。
9.2.8 誤信8：ネットワークは均一
どこでも同じ速度で通信できるという前提も成立しません。地域差・クラウドプロバイダー差・回線差・VPN差により、同じAPIへのリクエストでも東京からは高速、海外からは低速という差が生まれます。グローバルなシステムでは、ネットワークの非均一性を考慮した設計が求められます。
9.2.9 分散コンピューティングにおけるその他の考慮事項
8つの誤信は、分散システムにおける前提の危うさを示していました。しかし実際の現場では、さらに厄介な問題が存在します。本節では、分散化によって急激に難しくなる以下の3つの問題を整理します。
- 分散ロギング
- 分散トランザクション
- 契約管理
分散ロギング（Distributed Logging）
モノリスではログ管理は単純です。単一のアプリが出力する一つのログファイルを見れば、エラー・処理順序・スタックトレースをすべて追うことができます。
しかし分散システムでは、Client・API Gateway・Order Service・Payment Service・Inventory Serviceと処理が複数のサービスにまたがるため、ログも各サービスに分散します。注文失敗が発生した場合、Orderでは成功・Paymentでは失敗・Inventoryではタイムアウトといった状況が生じ、どこで問題が起きたのかを特定することが困難になります。
本書では、分散システムではリクエスト全体を追跡する仕組みが必要になると説明されています。そのために必要となるのが分散トレーシングです。Trace IDとSpan IDを用いてリクエストの流れを一貫して追跡する仕組みであり、OpenTelemetry・Jaeger・Zipkin・Datadog APMといったツールが代表例です。Trace IDなしに障害解析を行うことは、分散システムでは極めて困難です。
分散トランザクション（Distributed Transaction）
モノリスであればデータベースのACID特性により、複数テーブルへの更新をトランザクションで確実に保証できます。しかし分散システムでは、Order Service・Payment Service・Inventory Serviceがそれぞれ独立したデータベースを持つため、複数サービスにまたがるトランザクションの整合性を保つことが難しくなります。
注文は成功したが決済が失敗するといったデータ不整合が現実的に発生します。本書では、分散システムではトランザクション整合性が難しくなると説明されています。
この問題に対するアプローチとしてよく用いられるのがSagaパターンです。ロールバックではなく補償処理によって整合性を回復する考え方であり、注文・決済と処理を進め、失敗が発生した場合に補償処理で巻き戻します。すべての操作を同期的に強整合性で処理しようとすると、タイムアウトと可用性低下を招きます。これはCAP定理が示す一貫性・可用性・分断耐性のトレードオフとも直結する問題です。
契約管理（Contract Management）
ここでいう契約とは、サービス間のAPI仕様のことです。たとえば {"orderId": 123, "price": 1000} というJSONのフォーマットがサービス間の契約となります。
分散システムでは各サービスが独立してデプロイされるため、片方のサービスだけが変更されるという状況が発生します。API項目を削除したり型を変更したりすると、その契約に依存している別サービスがクラッシュするといった事故が起きます。本書では、分散システムでは契約の変更管理が極めて重要になると説明されています。
対策としてはAPIバージョニング（v1・v2という形での管理）、Consumer Driven ContractテストツールであるPactの活用、そして後方互換性の維持が挙げられます。項目の追加は比較的安全ですが、削除や変更は他サービスへの影響を慎重に考慮する必要があります。APIを自由に変更したり、スキーマを共有しすぎて強いコナーセンスを生じさせたりすることは、分散システムでは深刻な障害につながります。
9.2のまとめ
8つの誤信はいずれも、分散化によって初めて顕在化する問題です。モノリスでは意識する必要がなかったこれらの問題を、分散システムではすべて考慮しなければなりません。
また、本節で見てきた問題はすべて、「分散すると境界が増える」ことで発生しています。モノリスでは一つのプロセス・一つのDB・一つのログで完結していたものが、分散では複数のサービス・複数のDB・複数のログ・複数のチームへと広がり、急激に複雑化します。
本書が伝えるのは「分散はダメ」ということではなく、「分散化には相応の代償（複雑性との交換）がある」という現実です。分散アーキテクチャとは、ネットワーク障害を前提に設計されるものです。柔軟性が向上する一方で複雑性も増大する。このトレードオフを正しく認識したうえで、その複雑性を受け入れる価値があるかどうかを問い続けることが、アーキテクトに求められる姿勢といえます。解
まとめ
第9章では、アーキテクチャスタイルの基礎として、モノリス・クライアント／サーバー・分散アーキテクチャの考え方を整理しました。
本章のテーマを一言で表すなら、「分散は、思っている以上に難しい」です。
基礎的なパターン（9.1）
前半では、巨大な泥団子・ユニタリーアーキテクチャ・クライアント／サーバー・3層アーキテクチャという基本構造を振り返りました。
巨大な泥団子はどこからでもアクセス可能で責務が曖昧、依存関係が複雑な構造を失ったシステムです。ユニタリーアーキテクチャは1アプリ・1DB・1デプロイとしてシンプルで合理的な構造であり、クライアント／サーバーは現代Webアーキテクチャの原型、3層アーキテクチャはPresentation・Business・Databaseという責務分離の基礎です。
ここで見えてきたのは、アーキテクチャは「問題解決の歴史」であるということです。
モノリスと分散（9.2）
後半では、モノリシックアーキテクチャと分散アーキテクチャの違いを整理しました。
モノリスはシンプルでデバッグが容易、高速で運用しやすい反面、スケールしづらく障害や変更の影響範囲が大きくなります。分散は独立したデプロイ・スケール・障害分離が可能である一方、ネットワーク障害・レイテンシー・分散トランザクション・可観測性・契約管理といった問題を抱えます。柔軟性と複雑性のトレードオフです。
分散コンピューティングの8つの誤信
本章の中心テーマは「分散コンピューティングの8つの誤信」でした。ネットワークは信頼できる・レイテンシーはゼロ・帯域幅は無限・ネットワークは安全・トポロジーは変化しない・管理者は一人だけ・転送コストはゼロ・ネットワークは均一、これらはすべて実際のシステムでは成立しない前提です。本書はこれらをいずれも幻想であると強調しています。
分散化で追加される複雑性
さらに本章では、分散ロギング・分散トランザクション・契約管理も扱いました。モノリスでは1つのログ・1つのDB・1つのプロセスで完結していたものが、分散では複数のログ・複数のDB・複数のサービスへと広がり、難易度が急激に上がります。
本章の核心
本章を通じて本書が伝えるのは、分散アーキテクチャはモノリスより優れているわけではないという点です。重要なのは「必要だから分散する」という判断であり、「流行だから分散する」ことではありません。
終わりに
第8章では「どう分割するか」を学び、第9章では「分割した結果、何が起きるのか」を学びました。
ここで見えてくるのは、アーキテクチャとは「構造」を作ることではなく、「複雑性」を管理することであるという視点です。
モノリスはシンプルですが、大規模化すると柔軟性を失います。分散は柔軟ですが、その代償としてネットワーク・可用性・整合性・可観測性・運用という新たな複雑性を抱えます。アーキテクトが選択しているのは「どちらが優れているか」ではなく、**「どの複雑性を受け入れるか」**です。良いアーキテクチャとは、複雑性を消すものではなく、複雑性を適切な場所へ閉じ込めるものといえます。
第9章までで、モジュール性・アーキテクチャ特性・コナーセンス・コンポーネント・アーキテクチャ量子・分散の複雑性といった、アーキテクチャの基礎理論が一通り揃いました。
次章（第10章）からはいよいよ具体的なアーキテクチャスタイルに入ります。レイヤードアーキテクチャ・パイプライン・マイクロカーネル・サービスベース・イベント駆動・マイクロサービスなど、実際の構造パターンをそれぞれの強み・弱み・適用シーン・トレードオフの観点から比較しながら見ていきます。