はじめに
前章（第10章）では、Presentation・Business・Persistence・Databaseという技術責務による分割を行うレイヤードアーキテクチャを学びました。「関心の分離（Separation of Concerns）」によってシステムを整理する考え方です。
一方、本章で扱うパイプラインアーキテクチャはまったく異なる発想で設計されます。レイヤードアーキテクチャが「どの責務をどこへ配置するか」を考えるのに対し、パイプラインアーキテクチャは**「データがどのように流れるか」**を中心に設計します。
本書ではこのスタイルをパイプ＆フィルターアーキテクチャ（Pipe-and-Filter Architecture）とも呼んでいます。
実は私たちは日常的にこの考え方を利用しています。LinuxやMacのシェルで cat access.log | grep ERROR | sort | uniq というパイプ処理を使うとき、まさにパイプラインアーキテクチャの考え方そのものです。各コマンドは入力を受け取り・自分の責務だけを実行し・次へ渡すという単純なルールで動作しています。複雑な処理も、小さな処理を組み合わせることで実現できます。
現代のシステムでもETL・データ分析基盤・Kafkaストリーム処理・ログ処理・動画変換・AI推論パイプラインなどで広く利用されています。AIシステムであれば、画像入力・前処理・推論・後処理・結果出力という流れがその典型例です。
本章では、パイプとは何か・フィルターとは何か・なぜ高いモジュール性を実現できるのか・どのようなシステムに向いているのかを整理していきます。第10章が「構造中心」のアーキテクチャだったとすれば、第11章は「データフロー中心」のアーキテクチャです。
📖ソフトウェアアーキテクチャの基礎
本書は、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 自己評価のためのチェックリスト
参考文献
訳者あとがき
索引
関連書籍
11.1 トポロジー
パイプラインアーキテクチャの最大の特徴は、「データの流れを中心にシステムを構成する」ことです。レイヤードアーキテクチャが責務を上下に分割するのに対し、パイプラインアーキテクチャは入力・処理・出力というデータの流れそのものを設計します。
本書では、このアーキテクチャは**「パイプ（Pipe）」と「フィルター（Filter）」**という2つの要素から構成されると説明されています。
複数のフィルターがパイプによって接続されており、それぞれのフィルターは入力を受け取り・自分の処理を実行し・結果を次へ渡すという単純な責務だけを持ちます。巨大な処理を小さな処理の連鎖へと分解する考え方です。
この構造が強力な理由はシンプルです。各フィルターが独立しているため、あるフィルターを変更しても他のフィルターへの影響が小さく、高凝集・低結合を実現しやすい構造です。これは第3章で学んだ凝集度・結合度・コナーセンスの考え方とも直結しています。
11.1.1 パイプ
パイプとはフィルター同士を接続する通信経路です。Filter AからFilter Bへデータを渡す役割を担います。
本書ではパイプは一般的に一方向かつポイントツーポイント（P2P）であると説明されています。AからBへの通信はあっても、BからAへの通信はありません。双方向通信になるとフィルター同士が互いを意識し始め、依存関係が増加してモジュール性が低下します。そのためパイプラインアーキテクチャでは一方向通信が基本です。
11.1.2 フィルター
フィルターとは実際に処理を行うコンポーネントであり、パイプラインアーキテクチャの主役です。
本書では、フィルターは自己完結型・独立・ステートレスであることが望ましいと説明されています。入力・処理・出力だけに集中し、他のフィルターの内部実装を知る必要はありません。
本書ではフィルターを以下の4種類に分類しています。
プロデューサー（Producer） は処理の開始地点であり、Sourceとも呼ばれます。Kafka Consumerやファイル読込・API受信・センサー入力などが該当します。
トランスフォーマー（Transformer） は入力データを変換するフィルターです。JSON変換・データ加工・AI前処理・正規化などが該当し、関数型プログラミングのmapに近い役割です。
テスター（Tester） は条件判定を行うフィルターです。異常検知・エラーデータの除外・閾値判定などが該当し、関数型プログラミングのfilterに近い役割です。
コンシューマー（Consumer） は処理の終了地点です。DB保存・ファイル出力・API送信・画面表示などパイプラインの最終結果を扱います。
たとえばAI画像処理であれば、画像読込（Producer）・画像前処理（Transformer）・異常判定（Tester）・DB保存（Consumer）という流れになります。
11.1 まとめ
パイプラインアーキテクチャは、機能を分割するのではなく、**「処理の流れを分割する」**アーキテクチャです。レイヤードアーキテクチャのUI・Business・DBという構造中心の分割に対し、入力・変換・判定・出力というデータフロー中心の設計思想を持ちます。
- パイプラインアーキテクチャはパイプとフィルターという2つの要素で構成される
- パイプは一方向のポイントツーポイント通信経路である
- フィルターはProducer・Transformer・Tester・Consumerの4種類に分類される
- 各フィルターは独立・自己完結・ステートレスであることが望ましい
- Unixシェルのパイプ処理はその代表的な実装例である
- 高凝集・低結合を実現しやすく、モジュール性が高い構造である
11.2 事例
前節では、パイプ・フィルター・Producer・Transformer・Tester・Consumerという構成要素を整理しました。本節では、パイプラインアーキテクチャが実際にどのようなシステムで使われるかを見ていきます。
本書では、パイプラインアーキテクチャは単純な一方向データ処理と非常に相性が良いと説明されています。EDI・ETL・メッセージ処理・ストリーム処理などがその代表例です。
EDI（Electronic Data Interchange）
企業間データ連携では、受信・フォーマット変換・検証・出力という流れが典型的なパイプライン処理となります。受信したデータをXML・CSV・JSONなどへ変換し、検証して次のシステムへ渡す構造は、フィルターの連結そのものです。
ETL（Extract / Transform / Load）
本書でも代表例として紹介されているのがETLです。業務DBからデータを抽出し（Extract）、整形・集計して（Transform）、データウェアハウスへ格納する（Load）という流れは、パイプラインアーキテクチャの考え方と完全に一致しています。
Apache Camel
こちらも本書で例として紹介されています。異なるシステム間を接続する統合フレームワークであり、File・Transform・API・DBというルートを定義できます。フィルターを連結して処理を構成するという点でパイプラインアーキテクチャの典型例です。
Kafkaを利用したテレメトリ処理
本書で最も詳しく説明されているのが、図11-2のKafkaを利用したテレメトリ処理の例です。サービスから送信される稼働率・レスポンス時間・テレメトリ情報を処理するシステムであり、Kafka・Service Info Capture・Duration Filter・Duration Calculator・Database Output・MongoDBという構成になっています。
Service Info Capture（Producer） はKafkaからデータを取得することだけに責任を持ちます。
Duration Filter（Tester） は入力データがレスポンス時間情報を持っているかを判定します。対象データであれば次へ渡し、対象外であればパイプラインから除外します。
Duration Calculator（Transformer） はレスポンス時間の計算を行います。このフィルターが重要なのは、計算処理だけに集中しており、KafkaもDBも知らないという点です。独立した責務を持つフィルターの理想形です。
Database Output（Consumer） は最終結果をMongoDBへ保存します。
拡張性の高さ
本書がこの構造で特に強調するのが拡張性の高さです。たとえば新たにCPU使用率を分析したくなった場合、CPU FilterとCPU Calculatorを追加するだけで実現できます。既存のDuration Filterには影響しません。「機能追加＝フィルター追加」が成立しやすいことが、パイプラインアーキテクチャの大きな強みです。
これは各フィルターが独立しているからこそ実現できることであり、第3章で学んだ高凝集・低結合の考え方と直結しています。
11.2 まとめ
- パイプラインアーキテクチャはETL・EDI・ストリーム処理と相性が良い
- Producer・Tester・Transformer・Consumerという4種のフィルターで処理を構成できる
- 各フィルターは独立しており、変更の影響範囲を小さくできる
- 機能追加はフィルターの追加によって実現しやすく、拡張性が高い
- 高凝集・低結合を実現しやすく、データ処理基盤やAIシステムとも非常に相性が良い
11.3 アーキテクチャ特性の評価
ここまで見てきたように、パイプラインアーキテクチャは入力・変換・判定・出力という単純なデータフローを中心に構築されます。本節では、このアーキテクチャが保守・スケール・テストといった観点でどのように評価されるかを整理します。
本書では以下の通りアーキテクチャ特性を評価しています。
| 特性 | 評価 |
|---|---|
| デプロイ容易性 | ★★ |
| 弾力性 | ★ |
| 進化性 | ★★★ |
| 耐障害性 | ★ |
| モジュール性 | ★★★ |
| 全体的なコスト | ★★★★★ |
| パフォーマンス | ★★ |
| 信頼性 | ★★★ |
| スケーラビリティ | ★ |
| シンプルさ | ★★★★★ |
| テスト容易性 | ★★★ |
シンプルさ ★★★★★
本書で最も高く評価されている特性です。各フィルターは入力・処理・出力だけを考えればよく、CSV読込・整形・集計・出力といったETL処理であれば、各フィルターを独立して理解できます。レイヤードアーキテクチャのようにController・Service・Repositoryを横断して追いかける必要がないため、学習コストが低く理解しやすいという大きなメリットがあります。
全体的なコスト ★★★★★
こちらも高い評価です。一般的なパイプラインアーキテクチャは単一アプリ・単一デプロイとして実装されることが多く、Service Discovery・API Gateway・分散トレーシングといった仕組みが不要です。そのため構築コストと運用コストが比較的低くなります。
モジュール性 ★★★
パイプラインアーキテクチャの強みの一つです。たとえば画像前処理を変更したい場合、画像前処理フィルターだけを修正でき、他のフィルターへの影響が小さくなります。第3章で学んだ高凝集・低結合の観点からも優れた特性を持っています。
進化性 ★★★
新しい処理を追加しやすい点が評価されています。ログ分析システムに異常検知を追加したい場合、新しいフィルターを追加するだけで対応できるケースがあります。「機能追加＝フィルター追加」が成立しやすいことが、進化性の高さにつながっています。
テスト容易性 ★★★
フィルター単位でテストできるため、比較的高い評価です。たとえばDuration Calculatorであれば、入力データを与えて期待する結果になるかを確認するだけで済みます。単体テストがしやすい構造です。
信頼性 ★★★
モノリシックデプロイが多く、分散システムほど複雑ではないため中程度の評価です。ただしパイプラインの途中で障害が発生すると後続の処理も停止する可能性があり、極端に高い評価にはなりません。
デプロイ容易性 ★★
パイプライン全体が一つのデプロイ単位になりやすいため、フィルター単位での独立デプロイは基本的にできません。一部を修正した場合でも全体を再デプロイする必要が生じやすく、評価はやや低くなります。
パフォーマンス ★★
データが各フィルターを順番に通過する構造上、フィルター数が増えるほど処理時間も増加します。処理のオーバーヘッドが積み重なりやすく、パフォーマンスは高くありません。
スケーラビリティ ★/ 弾力性 ★ / 耐障害性 ★
これらはいずれも低評価です。通常は単一システムとして動作するため、一部だけを独立してスケールすることが苦手であり、マイクロサービスのような柔軟なスケーリングは基本的にできません。負荷に応じた動的な拡張・縮小も難しく、クラウドネイティブなアーキテクチャと比べると弾力性に欠けます。また、あるフィルターが停止すると後続処理も停止する単一障害点になりやすく、耐障害性も低くなります。
11.3 まとめ
パイプラインアーキテクチャは**「シンプルさ」と「モジュール性」を重視したアーキテクチャ**です。一方で高いスケーラビリティ・可用性・弾力性を求めるシステムには向きません。ETL・ログ処理・AI推論・動画変換のように処理フローが明確なシステムで真価を発揮します。
- シンプルさとコスト効率が最大の強みである
- フィルター単位での独立した理解・テスト・拡張が容易である
- スケーラビリティ・弾力性・耐障害性は低く、大規模分散システムには不向きである
- 処理フローが明確な一方向データ処理と非常に相性が良い
まとめ
第11章では「パイプラインアーキテクチャ」について整理しました。レイヤードアーキテクチャのようにUI・Business・DBという責務の分割ではなく、入力・変換・判定・出力というデータの流れ（Data Flow）を中心に設計するアーキテクチャです。
パイプとフィルター
本章ではまず、パイプラインアーキテクチャを構成するパイプとフィルターについて学びました。パイプはフィルター間を接続する通信経路であり、フィルターは実際の処理を担当するコンポーネントです。各フィルターは入力・処理・出力だけを担当し、他のフィルターの内部実装を知る必要がありません。この単純さが高いモジュール性の源泉となっています。
4種類のフィルター
本書ではフィルターをProducer（処理の開始地点）・Transformer（データ変換）・Tester（条件判定）・Consumer（結果出力）の4種類に分類しています。
実務ではCSV読込・整形・検証・DB保存というETL処理や、画像取得・前処理・AI推論・後処理・保存というAIパイプラインが代表例です。
Kafkaによる事例
本章では、Kafkaを利用したテレメトリ処理の事例も紹介されました。Kafka・Service Info Capture・Duration Filter・Duration Calculator・Database Output・MongoDBという構成で、各フィルターの責務が明確に分離されています。新たにCPU使用率分析を追加したい場合はCPU FilterとCPU Calculatorを追加するだけで済みます。「機能追加＝フィルター追加」が成立しやすいことが、このアーキテクチャの大きな強みです。
アーキテクチャ特性
シンプルさと全体コストは最高評価であり、モジュール性と進化性も中程度の高さを持ちます。一方でスケーラビリティ・弾力性・耐障害性は低評価です。パイプラインアーキテクチャは「シンプルで変更しやすい」一方で「大規模分散システムには向かない」という特徴を持っています。
本章の核心
第11章を通じて本書が伝えるのは、「複雑な処理は、小さな処理の連鎖へ分解できる」という考え方です。巨大な処理を一つで作るのではなく、小さな責務を連鎖させて組み立てる。これは第3章で学んだ高凝集・低結合という考え方にも通じています。
終わりに
第10章では「構造をどう分割するか」を中心に考えるレイヤードアーキテクチャを学び、第11章では「データをどう流すか」を中心に考えるパイプラインアーキテクチャを見てきました。アーキテクチャは「何を中心にシステムを分割するか」によって大きく姿を変えます。
本章で登場したProducer・Transformer・Tester・Consumerという考え方は、ETL・Kafka Streams・Apache Camel・動画変換・ログ解析・AI推論基盤など、現代のシステムで数多く利用されています。データ収集・前処理・特徴抽出・推論・後処理・保存というAIの処理フローは、まさにパイプラインアーキテクチャそのものです。本章は単なる古典的なアーキテクチャスタイルの紹介ではなく、現代のデータ基盤やAIシステムを理解するための重要な基礎でもあります。
良いパイプラインアーキテクチャとは、複雑な処理を小さな責務へ分解し、流れとして組み立てられるアーキテクチャです。
第11章までで、モジュール性・コナーセンス・アーキテクチャ量子・レイヤードアーキテクチャ・パイプラインアーキテクチャといった主要な基礎スタイルが揃いました。
次章（第12章）では「マイクロカーネルアーキテクチャ」を扱います。IDE・ブラウザ・OS・プラグインシステムなどで広く利用されているこのアーキテクチャでは、「拡張性（Extensibility）」を中心テーマとしたアーキテクチャスタイルへと議論が移っていきます。