進化的アーキテクチャ (Neal Ford, Rebecca Parsons, Patrick Kua)

書籍情報

• 著者:Neal Ford(著), Rebecca Parsons(著), Patrick Kua(著), 島田 浩二(訳)
• 発行日:2018-08-17
• ISBN:9784873118567
• URL:https://www.oreilly.co.jp/books/9784873118567/

書籍目次

• 本書への推薦の言葉
• 訳者まえがき
• マーチン・ファウラーによる序文
• はじめに
• 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 (1) 進化の影響を受ける次元を特定する
    • 6.1.2 (2) それぞれの次元に対して適応度関数を定義する
    • 6.1.3 (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枚のピザ」チーム
  • ケーススタディ:オープンソースライブラリの合法性
  • インフラストラクチャはアーキテクチャに影響を与える