本書への推薦の言葉
訳者まえがき
マーチン・ファウラーによる序文
はじめに

1章　ソフトウェアアーキテクチャ
    1.1　進化的アーキテクチャ
        1.1.1　全てがひっきりなしに変化していく中で、長期的な計画がどれくらい可能か
        1.1.2　いったん構築したアーキテクチャを経年劣化から防ぐにはどうすればよいか
    1.2　漸進的な変更
    1.3　誘導的な変更
    1.4　アーキテクチャの多重な次元
    1.5　コンウェイの法則
    1.6　なぜ進化なのか
    1.7　まとめ

2章　適応度関数
    2.1　適応度関数とは
    2.2　分類
        2.2.1　アトミック vs ホリスティック
        2.2.2　トリガー式 vs 継続的
        2.2.3　静的 vs 動的
        2.2.4　自動 vs 手動
        2.2.5　一時的なもの
        2.2.6　創発よりも意図的
        2.2.7　ドメイン特化なもの
    2.3　早い段階で適応度関数を特定する
    2.4　適応度関数を見直す

3章　漸進的な変更を支える技術
    3.1　構成要素
        3.1.1　テスト可能
        3.1.2　デプロイメントパイプライン
        3.1.3　適応度関数の分類を組み合わせる
        3.1.4　ケーススタディ：60回/日のデプロイごとのアーキテクチャ再構築
        3.1.5　目標の衝突
        3.1.6　ケーススタディ：PenultimateWidgetsの請求書発行サービスに適応度関数を追加する
    3.2　仮説駆動開発とデータ駆動開発
    3.3　ケーススタディ：移植するのは何か

4章　アーキテクチャ上の結合
    4.1　モジュール性
    4.2　アーキテクチャ量子と粒度
    4.3　アーキテクチャスタイルの進化可能性
        4.3.1　巨大な泥団子
        4.3.2　モノリス（一枚岩）
        4.3.3　イベント駆動アーキテクチャ
        4.3.4　サービス指向アーキテクチャ
        4.3.5　「サーバーレス」アーキテクチャ
    4.4　量子の大きさをコントロールする
    4.5　ケーススタディ：コンポーネント循環を防ぐ

5章　進化的データ
    5.1　進化的なデータベース設計
        5.1.1　スキーマを進化させる
        5.1.2　共有データベース統合
    5.2　不適切なデータ結合
        5.2.1　2相コミットトランザクション
        5.2.2　データの年齢と質
    5.3　ケーススタディ：PenultimateWidgetsのルーティングを進化させる

6章　進化可能なアーキテクチャの構築
    6.1　仕組み
        6.1.1　①進化の影響を受ける次元を特定する
        6.1.2　②それぞれの次元に対して適応度関数を定義する
        6.1.3　③デプロイメントパイプラインを使って適応度関数を自動化する
    6.2　グリーンフィールドプロジェクト
    6.3　既存のアーキテクチャを改良する
        6.3.1　適切な結合と凝集
        6.3.2　開発プラクティス
        6.3.3　適応度関数
        6.3.4　COTSとの関わり合い
    6.4　アーキテクチャの移行
        6.4.1　移行手順
        6.4.2　モジュール相互作用を進化させる
    6.5　進化的アーキテクチャ構築のための手引き
        6.5.1　不要な変数を取り除く
        6.5.2　決定を可逆にする
        6.5.3　予測可能ではなく進化可能を選ぶ
        6.5.4　腐敗防止層を構築する
        6.5.5　ケーススタディ：サービステンプレート
        6.5.6　犠牲的アーキテクチャの構築
        6.5.7　外部の変更を軽減する
        6.5.8　ライブラリのアップデートとフレームワークのアップデート
        6.5.9　スナップショットよりも継続的デリバリーを選ぶ
        6.5.10　内部的にサービスをバージョン付けする
    6.6　ケーススタディ：PenultimateWidgetsの評価サービスの進化

7章　進化的アーキテクチャの落とし穴とアンチパターン
    7.1　技術アーキテクチャ
        7.1.1　アンチパターン：ベンダーキング
        7.1.2　落とし穴：抽象化の欠如
        7.1.3　アンチパターン：ラスト10%の罠
        7.1.4　アンチパターン：コード再利用の乱用
        7.1.5　ケーススタディ：PenultimateWidgetsにおける再利用
        7.1.6　落とし穴：レジュメ駆動開発
    7.2　漸進的な変更
        7.2.1　アンチパターン：不適切なガバナンス
        7.2.2　ケーススタディ：PenultimateWidgetsにおけるゴルディロックスガバナンス
        7.2.3　落とし穴：リリース速度の欠如
    7.3　ビジネス上の関心事
        7.3.1　落とし穴：製品のカスタマイズ
        7.3.2　アンチパターン：レポート機能
        7.3.3　落とし穴：計画範囲

8章　進化的アーキテクチャの実践
    8.1　組織的要因
        8.1.1　機能横断型チーム
        8.1.2　ビジネス能力を中心とした組織化
        8.1.3　プロジェクトよりもプロダクト
        8.1.4　外部変化の取り扱い
        8.1.5　チームメンバー間の結びつき
    8.2　チーム結合特性
        8.2.1　文化
        8.2.2　実験の文化
    8.3　CFOと予算
    8.4　企業規模の適応度関数を構築する
        8.4.1　ケーススタディ：プラットフォームとしてのPenultimateWidgets
    8.5　どこから始めるか
        8.5.1　低い位置にぶらさがったフルーツ
        8.5.2　最大限の価値
        8.5.3　テスト
        8.5.4　インフラストラクチャ
        8.5.5　ケーススタディ：PenultimateWidgetsにおけるエンタープライズアーキテクチャ
    8.6　将来の展望
        8.6.1　AIを使った適応度関数
        8.6.2　生成的テスト
    8.7　なぜやるか（あるいは、なぜやらないか）
        8.7.1　企業が進化的アーキテクチャの構築を決断すべきなのはなぜか
        8.7.2　ケーススタディ：PenultimateWidgetsにおける選択的なスケール
        8.7.3　企業が進化的アーキテクチャの構築を決断すべきでないのはなぜか
        8.7.4　他者の説得
        8.7.5　ケーススタディ：コンサルティング柔道
    8.8　ビジネスケース
        8.8.1　「未来はすでにここにある」
        8.8.2　壊すことなく素早く動く
        8.8.3　リスクを減らす
        8.8.4　新しい能力
    8.9　進化的アーキテクチャの構築

参考文献
索引

コラム目次
    PenultimateWidgetsの紹介と、彼らが逆コンウェイ戦略を取る機会
    PenultimateWidgetsとエンタープライズアーキテクチャスプレッドシート
    継続的インテグレーション vs デプロイメントパイプライン
    PenultimateWidgetsのデプロイメントパイプライン
    本番環境における
    QA
    ドメイン駆動設計の境界づけられたコンテキスト
    モノリシックな
    Listing
    「無共有」と適切な結合
    DBA、ベンダー、ツールチェイン
    リファクタリングと再構築
    スノーフレークの危険性
    インターネットを壊した
    11行のコード
    IBMのサンフランシスコプロジェクト
    強制的な分離
    DevOpsの自動化による新しいリソースの発見
    Amazonの「2枚のピザ」チーム
    ケーススタディ：オープンソースライブラリの合法性
    インフラストラクチャはアーキテクチャに影響を与える