book

進化的アーキテクチャ ―絶え間ない変化を支える

by Neal Ford, Rebecca Parsons, Patrick Kua, 島田浩二

August 2018

Beginner to intermediate

240 pages

3h 2m

Japanese

O'Reilly Japan, Inc.

Read now

Unlock full access

1.1　進化的アーキテクチャ1.1.1　全てがひっきりなしに変化していく中で、長期的な計画がどれくらい可能か1.1.2　いったん構築したアーキテクチャを経年劣化から防ぐにはどうすればよいか1.2　漸進的な変更1.3　誘導的な変更1.4　アーキテクチャの多重な次元1.5　コンウェイの法則PenultimateWidgetsの紹介と、彼らが逆コンウェイ戦略を取る機会1.6　なぜ進化なのか1.7　まとめ
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　適応度関数を見直すPenultimateWidgetsとエンタープライズアーキテクチャスプレッドシート
3.1　構成要素3.1.1　テスト可能3.1.2　デプロイメントパイプライン継続的インテグレーション vs デプロイメントパイプラインPenultimateWidgetsのデプロイメントパイプライン本番環境におけるQA3.1.3　適応度関数の分類を組み合わせる3.1.4　ケーススタディ：60回/日のデプロイごとのアーキテクチャ再構築3.1.5　目標の衝突3.1.6　ケーススタディ：PenultimateWidgetsの請求書発行サービスに適応度関数を追加する3.2　仮説駆動開発とデータ駆動開発3.3　ケーススタディ：移植するのは何か

4.1　モジュール性4.2　アーキテクチャ量子と粒度ドメイン駆動設計の境界づけられたコンテキストモノリシックなListing4.3　アーキテクチャスタイルの進化可能性4.3.1　巨大な泥団子4.3.2　モノリス（一枚岩）4.3.3　イベント駆動アーキテクチャ4.3.4　サービス指向アーキテクチャ「無共有」と適切な結合4.3.5　「サーバーレス」アーキテクチャ4.4　量子の大きさをコントロールする4.5　ケーススタディ：コンポーネント循環を防ぐ
5.1　進化的なデータベース設計5.1.1　スキーマを進化させる5.1.2　共有データベース統合5.2　不適切なデータ結合DBA、ベンダー、ツールチェイン5.2.1　2相コミットトランザクション5.2.2　データの年齢と質5.3　ケーススタディ：PenultimateWidgetsのルーティングを進化させる
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　外部の変更を軽減するインターネットを壊した11行のコード6.5.8　ライブラリのアップデートとフレームワークのアップデート6.5.9　スナップショットよりも継続的デリバリーを選ぶ6.5.10　内部的にサービスをバージョン付けする6.6　ケーススタディ：PenultimateWidgetsの評価サービスの進化
7.1　技術アーキテクチャ7.1.1　アンチパターン：ベンダーキング7.1.2　落とし穴：抽象化の欠如7.1.3　アンチパターン：ラスト10%の罠IBMのサンフランシスコプロジェクト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.1　組織的要因8.1.1　機能横断型チームDevOpsの自動化による新しいリソースの発見8.1.2　ビジネス能力を中心とした組織化8.1.3　プロジェクトよりもプロダクトAmazonの「2枚のピザ」チーム8.1.4　外部変化の取り扱い8.1.5　チームメンバー間の結びつき8.2　チーム結合特性8.2.1　文化8.2.2　実験の文化8.3　CFOと予算8.4　企業規模の適応度関数を構築するケーススタディ：オープンソースライブラリの合法性8.4.1　ケーススタディ：プラットフォームとしてのPenultimateWidgets8.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　進化的アーキテクチャの構築