book

ソフトウェアアーキテクチャの基礎第2版 ―エンジニアリングに基づく体系的アプローチ

Name: ソフトウェアアーキテクチャの基礎 第2版 ―エンジニアリングに基づく体系的アプローチ
ISBN: 9784814401550

by Mark Richards, Neal Ford, 島田浩二

March 2026

Beginner to intermediate

560 pages

8h 12m

Japanese

O'Reilly Japan, Inc.

Read now

Unlock full access

　表紙
　大扉
　原書大扉
　クレジット
　本書への推薦の言葉
　はじめに
　1章　イントロダクション
　　1.1　ソフトウェアアーキテクチャの定義　　1.2　ソフトウェアアーキテクチャの法則　　1.3　アーキテクトへの期待　　　1.3.1　アーキテクチャ決定を下す　　　1.3.2　アーキテクチャを継続的に分析する　　　1.3.3　最新のトレンドを把握し続ける　　　1.3.4　決定の順守を徹底する　　　1.3.5　多様な技術に触れ、経験している　　　1.3.6　ビジネスドメインを理解している　　　1.3.7　対人スキルを持ち合わせている　　　1.3.8　政治を理解し、かじ取りする　　1.4　本書の構成
第I部　基礎
　2章　アーキテクチャ思考
　　2.1　アーキテクチャと設計　　　2.1.1　戦略的な決定と戦術的な決定　　　2.1.2　労力の度合い　　　2.1.3　トレードオフの重要性　　2.2　技術的な幅　　　氷漬け原始人アンチパターン　　　2.2.1　20分ルール　　　2.2.2　パーソナルレーダーの開発　　2.3　トレードオフを分析する　　2.4　ビジネスドライバーを理解する　　2.5　アーキテクティングとコーディングのバランスを取る　　2.6　アーキテクチャ思考はもっと広い
　3章　モジュール性
　　3.1　モジュール性と粒度　　3.2　モジュール性の定義　　　クラス以前：モジュールによる再利用　　　名前衝突のない言語：Java 1.0　　3.3　モジュール性の測定　　　3.3.1　凝集度　　　3.3.2　結合度　　　結合度のメトリクスはなぜこんなに似た名前なのか？　　　3.3.3　コアメトリクス　　　3.3.4　主系列からの距離　　　メトリクスの限界　　　3.3.5　コナーセンス　　3.4　モジュールからコンポーネントへ

　4章　アーキテクチャ特性
　　　「非機能要件」という言葉の寿命　　4.1　アーキテクチャ特性とシステム設計　　4.2　アーキテクチャ特性の（部分的な）リスト　　　4.2.1　運用アーキテクチャ特性　　　4.2.2　構造アーキテクチャ特性　　　4.2.3　クラウドアーキテクチャ特性　　　4.2.4　横断的アーキテクチャ特性　　　ソフトウェアアーキテクチャにおける多くの曖昧さ　　4.3　トレードオフと最も現実的なアーキテクチャ
　5章　アーキテクチャ特性を明らかにする
　　5.1　ドメインの関心事からアーキテクチャ特性を捉える　　5.2　複合アーキテクチャ特性　　5.3　アーキテクチャ特性を導き出す　　　アーキテクチャ・カタの起源　　　5.3.1　カタを使う　　5.4　事例：シリコンサンドイッチ　　　5.4.1　明示的なアーキテクチャ特性　　　5.4.2　暗黙的なアーキテクチャ特性　　　設計とアーキテクチャとトレードオフ　　5.5　アーキテクチャ特性の制限と優先順位付け　　　事例：ヴァーサ号
　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.3　スコープの影響　　　7.3.1　スコープとアーキテクチャスタイル　　　7.3.2　カタ：Going Green　　7.4　スコープの決定とクラウド
　8章　コンポーネントベース思考
　　8.1　論理コンポーネントの定義　　8.2　論理アーキテクチャと物理アーキテクチャ　　8.3　論理アーキテクチャの作成　　　8.3.1　核となるコンポーネントを識別する　　　8.3.2　コンポーネントにユーザーストーリーを割り当てる　　　8.3.3　役割と責務の分析　　　8.3.4　アーキテクチャ特性の分析　　　8.3.5　コンポーネントの再構成　　8.4　コンポーネントの結合　　　8.4.1　静的結合　　　8.4.2　一時的結合　　　8.4.3　デメテルの掟　　8.5　事例：「Going, Going, Gone」におけるコンポーネントの発見
第II部　アーキテクチャスタイル
　9章　基礎
　　9.1　スタイルとパターン　　　アーキテクチャスタイルはどこから来たのか？　　9.2　基礎的なパターン　　　9.2.1　巨大な泥団子　　　9.2.2　ユニタリーアーキテクチャ　　　9.2.3　クライアント／サーバー　　　3層アーキテクチャ、言語設計、長期的な影響　　9.3　アーキテクチャの分割　　　コンウェイの法則　　　9.3.1　カタ：シリコンサンドイッチにおける分割　　9.4　モノリシックアーキテクチャと分散アーキテクチャ　　　9.4.1　誤信1：ネットワークは信頼できる　　　9.4.2　誤信2：レイテンシーがゼロ　　　9.4.3　誤信3：帯域幅は無限　　　9.4.4　誤信4：ネットワークは安全　　　9.4.5　誤信5：トポロジーは決して変化しない　　　9.4.6　誤信6：管理者は一人だけ　　　9.4.7　誤信7：転送コストはゼロ　　　9.4.8　誤信8：ネットワークは均一　　　9.4.9　その他の誤信　　9.5　チームトポロジーとアーキテクチャ　　9.6　特定のアーキテクチャスタイルへ
　10章　レイヤードアーキテクチャ
　　10.1　トポロジー　　10.2　スタイルの詳細　　　10.2.1　レイヤーの分離　　　10.2.2　レイヤーの追加　　10.3　データトポロジー　　10.4　クラウドに関する考察　　10.5　一般的なリスク　　10.6　統制　　10.7　チームトポロジーに関する考察　　10.8　スタイルの特徴　　　10.8.1　いつ使うか　　　10.8.2　いつ使わないか　　10.9　例とユースケース
　11章　モジュラーモノリス
　　11.1　トポロジー　　11.2　スタイルの詳細　　　11.2.1　モノリシック構造　　　11.2.2　モジュラー構造　　　11.2.3　モジュール間通信　　11.3　データトポロジー　　11.4　クラウドに関する考察　　11.5　共通のリスク　　11.6　統制　　11.7　チームトポロジーに関する考察　　11.8　スタイルの特徴　　　11.8.1　いつ使うか　　　11.8.2　いつ使わないか　　11.9　例とユースケース
　12章　パイプラインアーキテクチャ
　　12.1　トポロジー　　12.2　スタイルの詳細　　　12.2.1　フィルター　　　12.2.2　パイプ　　12.3　データトポロジー　　12.4　クラウドに関する考察　　12.5　一般的なリスク　　12.6　統制　　12.7　チームトポロジーに関する考察　　12.8　スタイルの特徴　　　12.8.1　いつ使うか　　　12.8.2　いつ使わないか　　12.9　例とユースケース
　13章　マイクロカーネルアーキテクチャ
　　13.1　トポロジー　　13.2　スタイルの詳細　　　13.2.1　コアシステム　　　13.2.2　プラグインコンポーネント　　　13.2.3　「マイクロカーネル性」のスペクトラム　　　13.2.4　レジストリ　　　13.2.5　コントラクト　　13.3　データトポロジー　　13.4　クラウドに関する考察　　13.5　一般的なリスク　　　13.5.1　コアシステムの高い変動性　　　13.5.2　プラグインの依存関係　　13.6　統制　　13.7　チームトポロジーに関する考察　　13.8　スタイルの特徴　　13.9　例とユースケース
　14章　サービスベースアーキテクチャ
　　14.1　トポロジー　　14.2　スタイルの詳細　　　14.2.1　サービスの設計と粒度　　　14.2.2　ユーザーインターフェイスのオプション　　　14.2.3　APIゲートウェイのオプション　　14.3　データトポロジー　　14.4　クラウドに関する考察　　14.5　一般的なリスク　　14.6　統制　　14.7　チームトポロジーに関する考察　　14.8　スタイルの特徴　　14.9　例とユースケース
　15章　イベント駆動アーキテクチャ
　　15.1　トポロジー　　15.2　スタイルの詳細　　　15.2.1　イベントとメッセージの違い　　　15.2.2　派生イベント　　　15.2.3　拡張可能なイベントを送信する　　　15.2.4　非同期処理機構　　　15.2.5　ブロードキャスト機構　　　15.2.6　イベントペイロード　　　15.2.7　「ブヨの群れ」アンチパターン　　　15.2.8　エラー処理　　　15.2.9　データロスの防止　　　15.2.10　リクエスト・リプライ処理　　　15.2.11　メディエーター型イベント駆動アーキテクチャ　　15.3　データトポロジー　　　15.3.1　モノリシックデータベーストポロジー　　　15.3.2　ドメインデータベーストポロジー　　　15.3.3　専用データベーストポロジー　　15.4　クラウドに関する考察　　15.5　一般的なリスク　　15.6　統制　　15.7　チームトポロジーに関する考察　　15.8　スタイルの特徴　　　15.8.1　リクエストベースモデルとイベントベースモデルの選択　　15.9　例とユースケース
　16章　スペースベースアーキテクチャ
　　16.1　トポロジー　　16.2　スタイルの詳細　　　16.2.1　処理ユニット　　　16.2.2　仮想化ミドルウェア　　　16.2.3　メッセージンググリッド　　　16.2.4　データグリッド　　　16.2.5　処理グリッド　　　16.2.6　デプロイメントマネージャー　　　16.2.7　データポンプ　　　16.2.8　データライター　　　16.2.9　データリーダー　　16.3　データトポロジー　　16.4　クラウドに関する考察　　16.5　一般的なリスク　　　16.5.1　データベースからの頻繁な読み取り　　　16.5.2　データの同期と整合性　　　16.5.3　高データ量　　　16.5.4　データ衝突　　16.6　統制　　16.7　チームトポロジーに関する考察　　16.8　スタイルの特徴　　16.9　例とユースケース　　　16.9.1　コンサートチケット販売システム　　　16.9.2　オンラインオークションシステム
　17章　オーケストレーション駆動サービス指向アーキテクチャ
　　17.1　トポロジー　　17.2　スタイルの詳細　　　なぜサービスと呼ばれるものがこれほど多く存在しているのか？　　　17.2.1　分類　　　17.2.2　再利用……と結合　　17.3　データトポロジー　　　本当に？宣言的トランザクション？！　　17.4　クラウドに関する考察　　17.5　一般的なリスク　　17.6　統制　　17.7　チームトポロジーに関する考察　　17.8　スタイルの特徴　　17.9　例とユースケース
　18章　マイクロサービスアーキテクチャ
　　18.1　トポロジー　　18.2　スタイルの特徴　　　18.2.1　境界づけられたコンテキスト　　　18.2.2　粒度　　　18.2.3　データ分離　　　18.2.4　APIレイヤー　　　18.2.5　運用面での再利用　　　18.2.6　フロントエンド　　　18.2.7　通信　　　強制的な不均質性　　　18.2.8　コレオグラフィとオーケストレーション　　　18.2.9　トランザクションとサーガ　　18.3　データトポロジー　　18.4　クラウドに関する考察　　18.5　一般的なリスク　　18.6　統制　　18.7　チームトポロジーに関する考察　　18.8　スタイルの特徴　　18.9　例とユースケース
　19章　適切なアーキテクチャスタイルを選ぶ
　　19.1　アーキテクチャの「トレンド」の変化　　19.2　判断基準　　19.3　モノリスのケーススタディ：シリコンサンドイッチ　　　19.3.1　モジュラーモノリス　　　19.3.2　マイクロカーネル　　19.4　分散アーキテクチャのケーススタディ：Going, Going, Gone
　20章　アーキテクチャパターン
　　20.1　再利用　　　20.1.1　ドメインによる結合と運用による結合の分離　　　直交結合　　20.2　通信　　　20.2.1　オーケストレーションとコレオグラフィ　　20.3　CQRS　　20.4　インフラストラクチャ　　　20.4.1　ブローカーパターン
第III部　テクニックとソフトスキル
　21章　アーキテクチャ決定
　　21.1　アーキテクチャ決定に関するアンチパターン　　　21.1.1　資産防御アンチパターン　　　21.1.2　グラウンドホッグデーアンチパターン　　　21.1.3　メール駆動アーキテクチャアンチパターン　　21.2　アーキテクチャ上重要なもの　　21.3　アーキテクチャデシジョンレコード　　　21.3.1　基本構造　　　ADRとコメント募集（RFC）　　　21.3.2　例　　　21.3.3　ADRの保管　　　21.3.4　ADRをドキュメントとして使用する　　　21.3.5　ADRを標準として使用する　　　21.3.6　既存システムでのADRの使用　　　21.3.7　アーキテクチャ決定における生成AIとLLMの活用
　22章　アーキテクチャ上のリスクを分析する
　　22.1　リスクマトリクス　　22.2　リスクアセスメント　　22.3　リスクストーミング　　　22.3.1　フェーズ1：識別　　　22.3.2　フェーズ2：合意　　　22.3.3　フェーズ3：リスク軽減　　22.4　ユーザーストーリーリスク分析　　22.5　リスクストーミングのユースケース　　　22.5.1　可用性　　　22.5.2　弾力性　　　22.5.3　セキュリティ　　22.6　まとめ
　23章　アーキテクチャの図解
　　23.1　図解　　　23.1.1　ツール　　　制作物への不合理な愛着　　　レイヤーを装飾的にではなく、意味的に使用する　　　23.1.2　図解標準：UML、C4、ArchiMate　　　23.1.3　図解ガイドライン　　23.2　まとめ
　24章　効果的なチームにする
　　24.1　コラボレーション　　24.2　制約と境界　　24.3　アーキテクトのパーソナリティ　　　24.3.1　コントロールフリークアーキテクト　　　24.3.2　アームチェアアーキテクト　　　24.3.3　効果的なアーキテクト　　24.4　どの程度関与すべきか？　　24.5　チームの警告サイン　　　24.5.1　プロセスロス　　　24.5.2　多元的無知　　　24.5.3　責任の分散　　24.6　チェックリストの活用　　　ホーソン効果　　　24.6.1　開発者向けコード完成チェックリスト　　　24.6.2　ユニットテスト・機能テスト用チェックリスト　　　24.6.3　ソフトウェアリリース用チェックリスト　　24.7　ガイダンスの提供　　　ビジネス上の正当性が持つインパクト　　24.8　まとめ
　25章　交渉とリーダーシップのスキル
　　25.1　交渉とファシリテーション　　　25.1.1　ビジネスステークホルダーとの交渉　　　25.1.2　他のアーキテクトとの交渉　　　25.1.3　開発者との交渉　　25.2　リーダーとしてのソフトウェアアーキテクト　　　25.2.1　アーキテクチャの4つのC　　　25.2.2　プラグマティックでありながらもビジョナリーであること　　　25.2.3　手本を示してチームをリードする　　25.3　開発チームに溶け込む　　　開発者のフロー状態　　25.4　まとめ
　26章　アーキテクチャと交わるもの
　　26.1　アーキテクチャと実装　　　26.1.1　運用上の関心事　　　26.1.2　構造上の整合性　　　26.1.3　アーキテクチャの制約　　26.2　アーキテクチャとインフラストラクチャ　　　歴史：Pets.comと弾力的なスケーリングが必要な理由　　26.3　アーキテクチャとデータトポロジー　　　26.3.1　データベーストポロジー　　　26.3.2　アーキテクチャ特性　　　26.3.3　データ構造　　　26.3.4　読み書きの優先順位　　26.4　アーキテクチャとエンジニアリングプラクティス　　26.5　アーキテクチャとチームトポロジー　　26.6　アーキテクチャとシステム統合　　26.7　アーキテクチャと全社標準　　26.8　アーキテクチャとビジネス環境　　26.9　アーキテクチャと生成AI　　　26.9.1　生成AIをアーキテクチャに組み込む　　　26.9.2　生成AIをアシスタントとして活用する　　26.10　まとめ
　27章　ソフトウェアアーキテクチャの法則（再考）
　　27.1　第一法則：ソフトウェアアーキテクチャはトレードオフがすべてだ　　　27.1.1　共有ライブラリと共有サービス　　　27.1.2　同期メッセージングと非同期メッセージング　　　27.1.3　必然的帰結その一：トレードオフの見落とし　　　なぜ素晴らしいものを持てないのか――トレードオフ！　　　27.1.4　必然的帰結その二：一度だけではできない　　27.2　第二法則：「どうやって」よりも「なぜ」の方がずっと重要だ　　　27.2.1　コンテキスト無視アンチパターン　　27.3　極端な選択肢の間のどこか　　27.4　最後のアドバイス
　付録A　議論用の質問リスト
　参考文献
　訳者あとがき
　著者紹介
　奥付

Content preview from ソフトウェアアーキテクチャの基礎第2版 ―エンジニアリングに基づく体系的アプローチ

●著者紹介

Mark Richards（マーク・リチャーズ）

マイクロサービスやその他の分散アーキテクチャのアーキテクチャや設計、実装に携わる経験豊富な実践的ソフトウェアアーキテクト。開発者がソフトウェアアーキテクトになるための道のりを支援するWebサイトであるDeveloperToArchitect.comの創設者。

Neal Ford（ニール・フォード）

ThoughtWorksのディレクター、ソフトウェアアーキテクト、ミームラングラー（役職名。情報・文化の遺伝子体現者の意）。ThoughtWorksはエンドツーエンドのソフトウェア開発とデリバリーに特化したグローバルITコンサルタント企業。ThoughtWorksに入社する前は、ソフトウェアのトレーニングと開発で広く知られるThe DSW Group, Ltd.でCTOを務めていた。

●訳者紹介

島田浩二（しまだこうじ）

1978年、神奈川県生まれ。電気通信大学電気通信学部卒業。2009年に株式会社えにしテックを設立。2011年からは一般社団法人日本Rubyの会の理事も務める。主な訳書に『エンジニアリング統括責任者の手引き』『スタッフエンジニアの道』『ソフトウェアアーキテクチャの基礎』『ソフトウェアアーキテクチャ・ハードパーツ』『モノリスからマイクロサービスへ』『Design It!』『ユニコーン企業のひみつ』（オライリー・ジャパン）、『ソフトウェア設計の結合バランス』『ソフトウェアアーキテクトのための意思決定術』（インプレス）など。

●カバーの説明

表紙の動物は、スペイン語で“loro cacique”、ポルトガル語で“anacã”、“papagaio-de-coleira”、“vanaquiá”などと呼ばれる南アメリカ原産のヒオウギインコ（Deroptyus ...

Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.

Read now

Unlock full access

More than 5,000 organizations count on O’Reilly

O’Reilly covers everything we've got, with content to help us build a world-class technology community, upgrade the capabilities and competencies of our teams, and improve overall team performance as well as their engagement.

Julian F.

Head of Cybersecurity

I wanted to learn C and C++, but it didn't click for me until I picked up an O'Reilly book. When I went on the O’Reilly platform, I was astonished to find all the books there, plus live events and sandboxes so you could play around with the technology.

Addison B.

Field Engineer

I’ve been on the O’Reilly platform for more than eight years. I use a couple of learning platforms, but I'm on O'Reilly more than anybody else. When you're there, you start learning. I'm never disappointed.

Amir M.

Data Platform Tech Lead

I'm always learning. So when I got on to O'Reilly, I was like a kid in a candy store. There are playlists. There are answers. There's on-demand training. It's worth its weight in gold, in terms of what it allows me to do.

Mark W.

Embedded Software Engineer

Publisher Resources

ISBN: 9784814401550Publisher Website

Cloud Computing

Data Engineering

Data Science

AI & ML

Programming Languages

Software Architecture

IT/Ops

Security

Design

Business

Soft Skills