進化的アーキテクチャ (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 まとめ
- 1.1 進化的アーキテクチャ
- 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 ケーススタディ:移植するのは何か
- 3.1 構成要素
- 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のルーティングを進化させる
- 5.1 進化的なデータベース設計
- 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の評価サービスの進化
- 6.1 仕組み
- 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 落とし穴:計画範囲
- 7.1 技術アーキテクチャ
- 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 進化的アーキテクチャの構築
- 8.1 組織的要因
- 参考文献
- 索引
- コラム目次
- PenultimateWidgetsの紹介と、彼らが逆コンウェイ戦略を取る機会
- PenultimateWidgetsとエンタープライズアーキテクチャスプレッドシート
- 継続的インテグレーション vs デプロイメントパイプライン
- PenultimateWidgetsのデプロイメントパイプライン
- 本番環境における
- QA
- ドメイン駆動設計の境界づけられたコンテキスト
- モノリシックな
- Listing
- 「無共有」と適切な結合
- DBA、ベンダー、ツールチェイン
- リファクタリングと再構築
- スノーフレークの危険性
- インターネットを壊した
- 11行のコード
- IBMのサンフランシスコプロジェクト
- 強制的な分離
- DevOpsの自動化による新しいリソースの発見
- Amazonの「2枚のピザ」チーム
- ケーススタディ:オープンソースライブラリの合法性
- インフラストラクチャはアーキテクチャに影響を与える