XiV ー 目次 本書への推薦の言葉… 訳者まえがき .. マーチン・ファウラーによる序文… はじめに 1 章ソフトウェアアーキテクチャ .. 1.1 進化的アーキテクチャ .. 1.1.1 全てがひっきりなしに変化していく中で、長期的な計画が どれくらい可能か .. 1.1.2 いったん構築したアーキテクチャを経年劣化から防ぐには どうすればよいか . ⅶ浦 「 / 8 -0 ) -4 「 / 8 9 -1 つけ 4 〔 0 ・ 1 -1 -1 -1 ワ〕ワっワ朝ワ 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 動的…

目冫欠 XV 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 ケーススタディ : コンポーネント循環を防ぐ . 「 / 〔 / っ / 8 -0 一 3 〔 / 9 1 6 ワ 3 ワ 3 ワ 3 ワ 3 ワ〕 3 … 48 … 52 LO 【 0 9 -0 一 -4 〔 0 〔 / -1 -0- 5

XVi ー 5 章 6 章 目次 進化的テータ .. 5.1 5.2 5.3 進化的なデータベース設計 .. 5.1.1 スキーマを進化させる .. 5.1.2 共有データベース統合 .. 不適切なデータ結合… 5.2.1 2 相コミットトランザクション… 5.2.2 データの年齢と質 .. ケーススタディ : PenuItimateWidgets のルーティングを 進化させる .. 進化可能なアーキテクチャの構築 . 6.1 6.2 6.3 6.4 6.5 仕組み .. 6.1.1 ①進化の影響を受ける次元を特定する .. 6.1.3 ③デブロイメントパイプラインを使って適応度関数を 6.1.2 ②それぞれの次元に対して適応度関数を定義する .. 進化的アーキテクチャ構築のための手引き .. 6.4.2 モジュール相互作用を進化させる .. 6.4.1 移行手順… アーキテクチャの移行 .. 6.3.4 C げとの関わり合い 6.3.3 適応度関数… 6.3.2 開発プラクティス… 6.3.1 適切な結合と凝集… 既存のアーキテクチャを改良する .. グリーンフィールドプロジェクト . 自動化する .. 6.5.1 6.5.2 6.5.3 6.5.4 6.5.5 6.5.6 不要な変数を取り除く .. 決定を可逆にする… 予測可能ではなく進化可能を選ぶ .. 腐敗防止層を構築する .. ケーススタディ : サービステンプレート .. 犠牲的アーキテクチャの構築 .. … 1 03 … 144 … 142 … 140 … 139 … 138 … 135 … 134 … 130 … 127 … 126 … 124 … 123 … 123 … 122 … 122 … 121 … 120 … 120 … 119 … 119 … 1 1 9 … 116 … 115 … 113 … 111 … 106 … 104 … 103

6.5.7 6.5.8 6.5.9 目次 スナップショットよりも継続的デリバリーを選ぶ… アップデート . ライプラリのアップデートとフレームワークの 外部の変更を軽減する .. 6.5.10 内部的にサービスをバージョン付けする .. 6.6 ケーススタディ : PenultimateWidgets の評価サービスの進化… 進化的アーキテクチャの落とし穴とアンチバターン… ー XVii … 148 … 150 … 151 … 152 … 1 55 … 146 7 章 8 章 7.1 7.2 7.3 技術アーキテクチャ .. アンチパターン : べンダーキング . 落とし穴 : 抽象化の欠如 .. アンチパターン : ラスト 10 % の罠… アンチパターン : コード再利用の乱用… ケーススタディ : PenuItimateWidgets に 落とし穴 : レジュメ駆動開発… 7.1.1 7.1.2 7.1.3 7.1.4 7.1.5 7.1.6 ーおける再利用 .. … 164 漸進的な変更… 7.2.1 アンチパターン : 不適切なガバナンス .. 7.2.2 ケーススタディ : PenultimateWidgets における ゴルデイロックスガバナンス .. 7.2.3 落とし穴 : リリース速度の欠如 .. ビジネス上の関心事… 落とし穴 : 製品のカスタマイズ .. アンチパターン : レポート機能 .. 落とし穴 : 計画範囲… 進化的アーキテクチャの実践 .. 7.3.3 7.3.2 7.3.1 8.1 組織的要因… 8.1.1 8.1.2 8.1.3 8.1.4 8.1.5 機能横断型チーム… ビジネス能力を中心とした組織化 .. プロジェクトよりもプロダクト .. 外部変化の取り扱い . チームメンバー間の結びつき .. … 155 … 155 … 157 … 160 … 162 … 165 … 166 … 166 … 169 … 170 … 172 … 172 … 173 … 175 … 1 77 … 177 … 177 … 180 … 181 … 182 … 184

XViii ー 目次 8.2 8.3 8.4 8.5 8.6 8.7 8.8 8.9 チーム結合特性 .. 8.2.1 文化 .. 8.2.2 実験の文化… CFO と予算 .. 企業規模の適応度関数を構築する .. どこから始めるか PenultimateWidgets.. 8.4.1 ケーススタディ : プラットフォームとしての 8.5.1 8.5.2 8.5.3 8.5.4 8.5.5 低い位置にぶらさがったフルーツ .. 最大限の価値 .. テスト . インフラストラクチャ . 工ンタープライズアーキテクチャ . ケーススタディ : PenultimateWidgets における 将来の展望 .. 8.6.1 用を使った適応度関数… 8.6.2 生成的テスト .. なぜやるか ( あるいは、なぜやらないか ) .. 8.7.1 8.7.2 8.7.3 8.7.4 8.7.5 企業が進化的アーキテクチャの構築を決断すべきなのは なぜか . ケーススタディ : PenultimateWidgets における 選択的なスケール… 企業が進化的アーキテクチャの構築を決断すべきでない ケーススタディ : コンサルティング柔道 .. 他者の説得 .. のはなせか . ビジネスケース . 進化的アーキテクチャの構築… 8.8.4 新しい能力 .. 8.8.3 リスクを減らす .. 8.8.2 壊すことなく素早く動く . 8.8.1 「未来はすで ( … 185 … 185 … 187 … 189 … 191 … 198 … 198 … 198 … 197 ... 196 … 195 … 194 … 193 ... 193 … 193 … 192 … 198 … 201 … 207 … 207 … 207 … 206 … 206 … 206 … 205 … 205 … 203

目冫欠 参考文献… 索引 .. コラム目次 PenultimateWidgets の紹介と、彼らが逆コンウェイ戦略を取る機会 . PenultimateWidgets とエンタープライズアーキテクチャスプレッドシート… 30 継続的インテグレーション vs デブロイメントパイプライン .. PenultimateWidgets のデブロイメントパイプライン .. 本番環境における QA... ドメイン駆動設計の境界づけられたコンテキスト .. モノリシックな Listing … 「無共有」と適切な結合… DBA 、べンダー、ツールチェイン . リファクタリングと再構築 .. スノーフレークの危険性 .. インターネットを壊した 11 行のコード .. IBM のサンフランシスコプロジェクト . 強制的な分離… DevOps の自動化による新しいリソースの発見… Amazon の「 2 枚のピザ」チーム .. インフラストラクチャはアーキテクチャに影響を与える . ケーススタディ : オープンソースライプラリの合法性 .. ー XiX … 209 … 212 … 16 … 41 … 43 … 45 … 63 … 92 … 112 … 124 … 137 … 147 … 161 … 168 … 179 … 182 ... 191 … 195

進化的アーキテクチャ 絶え間ない変化を支える 2018 年 8 月 17 日 訳 発 著 行 者 者 人 作 印刷・製本 発 行 所 兀 初版第 1 刷発行 Neal Ford ( ニール・フォード ) 、 Rebecca Parsons ( レベッカ・パーソンズ ) 、 Fax ( 03 ) 3233-3440 Tel ( 03 ) 3233-0641 ( 代表 ) 〒 101-8460 東京都千代田区神田錦町 3-1 株式会社オーム社 電子メール j 叩an@oreilly.co.jp Fax ( 03 ) 335 5263 Tel ( 03 ) 335 5227 〒 160-0002 東京都新宿区四谷坂町 12 番 22 号 ジャノヾン 株式会社オライリー 株式会社平河工業社 株式会社トップスタジオ テイム・オライリー 島田浩二 ( しまだこうじ ) Patrick Kua ( パトリック・クア ) printed in Japan ( ISBN97 & 4-87311-85 7 ) 乱丁、落丁の際はお取り替えいたします。 います。 パンから文書による許諾を得ずに、いかなる方法においても無断で複写、複製することは禁じられて 本書は著作権上の保護を受けています。本書の一部あるいは全部について、株式会社オライリー・ジャ