ソフトウェアアーキテクチャの基礎 第2版

本書への推薦の言葉
はじめに

1章　イントロダクション
    1.1　ソフトウェアアーキテクチャの定義
    1.2　ソフトウェアアーキテクチャの法則
    1.3　アーキテクトへの期待
        1.3.1　アーキテクチャ決定を下す
        1.3.2　アーキテクチャを継続的に分析する
        1.3.3　最新のトレンドを把握し続ける
        1.3.4　決定の順守を徹底する
        1.3.5　多様な技術に触れ、経験している
        1.3.6　ビジネスドメインを理解している
        1.3.7　対人スキルを持ち合わせている
        1.3.8　政治を理解し、かじ取りする
    1.4　本書の構成

第I部　基礎

2章　アーキテクチャ思考
    2.1　アーキテクチャと設計
        2.1.1　戦略的な決定と戦術的な決定
        2.1.2　労力の度合い
        2.1.3　トレードオフの重要性
    2.2　技術的な幅
        2.2.1　20 分ルール
        2.2.2　パーソナルレーダーの開発
    2.3　トレードオフを分析する
    2.4　ビジネスドライバーを理解する
    2.5　アーキテクティングとコーディングのバランスを取る
    2.6　アーキテクチャ思考はもっと広い

3章　モジュール性
    3.1　モジュール性と粒度
    3.2　モジュール性の定義
    3.3　モジュール性の測定
        3.3.1　凝集度
        3.3.2　結合度
        3.3.3　コアメトリクス
        3.3.4　主系列からの距離
        3.3.5　コナーセンス
    3.4　モジュールからコンポーネントへ

4章　アーキテクチャ特性
    4.1　アーキテクチャ特性とシステム設計
    4.2　アーキテクチャ特性の（部分的な）リスト
        4.2.1　運用アーキテクチャ特性
        4.2.2　構造アーキテクチャ特性
        4.2.3　クラウドアーキテクチャ特性
        4.2.4　横断的アーキテクチャ特性
    4.3　トレードオフと最も現実的なアーキテクチャ

5章　アーキテクチャ特性を明らかにする
    5.1　ドメインの関心事からアーキテクチャ特性を捉える
    5.2　複合アーキテクチャ特性
    5.3　アーキテクチャ特性を導き出す
        5.3.1　カタを使う
    5.4　事例：シリコンサンドイッチ
        5.4.1　明示的なアーキテクチャ特性
        5.4.2　暗黙的なアーキテクチャ特性
    5.5　アーキテクチャ特性の制限と優先順位付け

6章　アーキテクチャ特性の測定と統制
    6.1　アーキテクチャ特性の測定
        6.1.1　運用アーキテクチャ特性の測定
        6.1.2　構造アーキテクチャ特性の測定
        6.1.3　プロセスアーキテクチャ特性の測定
    6.2　統制と適応度関数
        6.2.1　アーキテクチャ特性の統制
        6.2.2　適応度関数

7章　アーキテクチャ特性のスコープ
    7.1　アーキテクチャ量子と粒度
    7.2　同期通信
    7.3　スコープの影響
        7.3.1　スコープとアーキテクチャスタイル
        7.3.2　カタ：Going Green
    7.4　スコープの決定とクラウド

8章　コンポーネントベース思考
    8.1　論理コンポーネントの定義
    8.2　論理アーキテクチャと物理アーキテクチャ
    8.3　論理アーキテクチャの作成
        8.3.1　核となるコンポーネントを識別する
        8.3.2　コンポーネントにユーザーストーリーを割り当てる
        8.3.3　役割と責務の分析
        8.3.4　アーキテクチャ特性の分析
        8.3.5　コンポーネントの再構成
    8.4　コンポーネントの結合
        8.4.1　静的結合
        8.4.2　一時的結合
        8.4.3　デメテルの掟
    8.5　事例：「Going, Going, Gone」におけるコンポーネントの発見

第II部　アーキテクチャスタイル

9章　基礎
    9.1　スタイルとパターン
    9.2　基礎的なパターン
        9.2.1　巨大な泥団子
        9.2.2　ユニタリーアーキテクチャ
        9.2.3　クライアント／サーバー
    9.3　アーキテクチャの分割
        9.3.1　カタ：シリコンサンドイッチにおける分割
    9.4　モノリシックアーキテクチャと分散アーキテクチャ
        9.4.1　誤信1：ネットワークは信頼できる
        9.4.2　誤信2：レイテンシーがゼロ
        9.4.3　誤信3：帯域幅は無限
        9.4.4　誤信4：ネットワークは安全
        9.4.5　誤信5：トポロジーは決して変化しない
        9.4.6　誤信6：管理者は一人だけ
        9.4.7　誤信7：転送コストはゼロ
        9.4.8　誤信8：ネットワークは均一
        9.4.9　その他の誤信
    9.5　チームトポロジーとアーキテクチャ
    9.6　特定のアーキテクチャスタイルへ

10章　レイヤードアーキテクチャ
    10.1　トポロジー
    10.2　スタイルの詳細
        10.2.1　レイヤーの分離
        10.2.2　レイヤーの追加
    10.3　データトポロジー
    10.4　クラウドに関する考察
    10.5　一般的なリスク
    10.6　統制
    10.7　チームトポロジーに関する考察
    10.8　スタイルの特徴
        10.8.1　いつ使うか
        10.8.2　いつ使わないか
    10.9　例とユースケース

11章　モジュラーモノリス
    11.1　トポロジー
    11.2　スタイルの詳細
        11.2.1　モノリシック構造
        11.2.2　モジュラー構造
        11.2.3　モジュール間通信
    11.3　データトポロジー
    11.4　クラウドに関する考察
    11.5　共通のリスク
    11.6　統制
    11.7　チームトポロジーに関する考察
    11.8　スタイルの特徴
        11.8.1　いつ使うか
        11.8.2　いつ使わないか
    11.9　例とユースケース

12章　パイプラインアーキテクチャ
    12.1　トポロジー
    12.2　スタイルの詳細
        12.2.1　フィルター
        12.2.2　パイプ
    12.3　データトポロジー
    12.4　クラウドに関する考察
    12.5　一般的なリスク
    12.6　統制
    12.7　チームトポロジーに関する考察
    12.8　スタイルの特徴
        12.8.1　いつ使うか
        12.8.2　いつ使わないか
    12.9　例とユースケース

13章　マイクロカーネルアーキテクチャ
    13.1　トポロジー
    13.2　スタイルの詳細
        13.2.1　コアシステム
        13.2.2　プラグインコンポーネント
        13.2.3　「マイクロカーネル性」のスペクトラム
        13.2.4　レジストリ
        13.2.5　コントラクト
    13.3　データトポロジー
    13.4　クラウドに関する考察
    13.5　一般的なリスク
        13.5.1　コアシステムの高い変動性
        13.5.2　プラグインの依存関係
    13.6　統制
    13.7　チームトポロジーに関する考察
    13.8　スタイルの特徴
    13.9　例とユースケース

14章　サービスベースアーキテクチャ
    14.1　トポロジー
    14.2　スタイルの詳細
        14.2.1　サービスの設計と粒度
        14.2.2　ユーザーインターフェイスのオプション
        14.2.3　API ゲートウェイのオプション
    14.3　データトポロジー
    14.4　クラウドに関する考察
    14.5　一般的なリスク
    14.6　統制
    14.7　チームトポロジーに関する考察
    14.8　スタイルの特徴
    14.9　例とユースケース

15章　イベント駆動アーキテクチャ
    15.1　トポロジー
    15.2　スタイルの詳細
        15.2.1　イベントとメッセージの違い
        15.2.2　派生イベント
        15.2.3　拡張可能なイベントを送信する
        15.2.4　非同期処理機構
        15.2.5　ブロードキャスト機構
        15.2.6　イベントペイロード
        15.2.7　「ブヨの群れ」アンチパターン
        15.2.8　エラー処理
        15.2.9　データロスの防止
        15.2.10　リクエスト・リプライ処理
        15.2.11　メディエーター型イベント駆動アーキテクチャ
    15.3　データトポロジー
        15.3.1　モノリシックデータベーストポロジー
        15.3.2　ドメインデータベーストポロジー
        15.3.3　専用データベーストポロジー
    15.4　クラウドに関する考察
    15.5　一般的なリスク
    15.6　統制
    15.7　チームトポロジーに関する考察
    15.8　スタイルの特徴
        15.8.1　リクエストベースモデルとイベントベースモデルの選択
    15.9　例とユースケース

16章　スペースベースアーキテクチャ
    16.1　トポロジー
    16.2　スタイルの詳細
        16.2.1　処理ユニット
        16.2.2　仮想化ミドルウェア
        16.2.3　メッセージンググリッド
        16.2.4　データグリッド
        16.2.5　処理グリッド
        16.2.6　デプロイメントマネージャー
        16.2.7　データポンプ
        16.2.8　データライター
        16.2.9　データリーダー
    16.3　データトポロジー
    16.4　クラウドに関する考察
    16.5　一般的なリスク
        16.5.1　データベースからの頻繁な読み取り
        16.5.2　データの同期と整合性
        16.5.3　高データ量
        16.5.4　データ衝突
    16.6　統制
    16.7　チームトポロジーに関する考察
    16.8　スタイルの特徴
    16.9　例とユースケース
        16.9.1　コンサートチケット販売システム
        16.9.2　オンラインオークションシステム

17章　オーケストレーション駆動サービス指向アーキテクチャ
    17.1　トポロジー
    17.2　スタイルの詳細
        17.2.1　分類
        17.2.2　再利用……と結合
    17.3　データトポロジー
    17.4　クラウドに関する考察
    17.5　一般的なリスク
    17.6　統制
    17.7　チームトポロジーに関する考察
    17.8　スタイルの特徴
    17.9　例とユースケース

18章　マイクロサービスアーキテクチャ
    18.1　トポロジー
    18.2　スタイルの特徴
        18.2.1　境界づけられたコンテキスト
        18.2.2　粒度
        18.2.3　データ分離
        18.2.4　API レイヤー
        18.2.5　運用面での再利用
        18.2.6　フロントエンド
        18.2.7　通信
        18.2.8　コレオグラフィとオーケストレーション
        18.2.9　トランザクションとサーガ
    18.3　データトポロジー
    18.4　クラウドに関する考察
    18.5　一般的なリスク
    18.6　統制
    18.7　チームトポロジーに関する考察
    18.8　スタイルの特徴
    18.9　例とユースケース

19章　適切なアーキテクチャスタイルを選ぶ
    19.1　アーキテクチャの「トレンド」の変化
    19.2　判断基準
    19.3　モノリスのケーススタディ：シリコンサンドイッチ
        19.3.1　モジュラーモノリス
        19.3.2　マイクロカーネル
    19.4　分散アーキテクチャのケーススタディ：Going, Going, Gone

20章　アーキテクチャパターン
    20.1　再利用
        20.1.1　ドメインによる結合と運用による結合の分離
    20.2　通信
        20.2.1　オーケストレーションとコレオグラフィ
    20.3　CQRS
    20.4　インフラストラクチャ
        20.4.1　ブローカーパターン

第III部　テクニックとソフトスキル

21章　アーキテクチャ決定
    21.1　アーキテクチャ決定に関するアンチパターン
        21.1.1　資産防御アンチパターン
        21.1.2　グラウンドホッグデーアンチパターン
        21.1.3　メール駆動アーキテクチャアンチパターン
    21.2　アーキテクチャ上重要なもの
    21.3　アーキテクチャデシジョンレコード
        21.3.1　基本構造
        21.3.2　例
        21.3.3　ADR の保管
        21.3.4　ADR をドキュメントとして使用する
        21.3.5　ADR を標準として使用する
        21.3.6　既存システムでのADR の使用
        21.3.7　アーキテクチャ決定における生成AI とLLM の活用

22章　アーキテクチャ上のリスクを分析する
    22.1　リスクマトリクス
    22.2　リスクアセスメント
    22.3　リスクストーミング
        22.3.1　フェーズ1：識別
        22.3.2　フェーズ2：合意
        22.3.3　フェーズ3：リスク軽減
    22.4　ユーザーストーリーリスク分析
    22.5　リスクストーミングのユースケース
        22.5.1　可用性
        22.5.2　弾力性
        22.5.3　セキュリティ
    22.6　まとめ

23章　アーキテクチャの図解
    23.1　図解
        23.1.1　ツール
        23.1.2　図解標準：UML、C4、ArchiMate
        23.1.3　図解ガイドライン
    23.2　まとめ

24章　効果的なチームにする
    24.1　コラボレーション
    24.2　制約と境界
    24.3　アーキテクトのパーソナリティ
        24.3.1　コントロールフリークアーキテクト
        24.3.2　アームチェアアーキテクト
        24.3.3　効果的なアーキテクト
    24.4　どの程度関与すべきか？
    24.5　チームの警告サイン
        24.5.1　プロセスロス
        24.5.2　多元的無知
        24.5.3　責任の分散
    24.6　チェックリストの活用
        24.6.1　開発者向けコード完成チェックリスト
        24.6.2　ユニットテスト・機能テスト用チェックリスト
        24.6.3　ソフトウェアリリース用チェックリスト
    24.7　ガイダンスの提供
    24.8　まとめ

25章　交渉とリーダーシップのスキル
    25.1　交渉とファシリテーション
        25.1.1　ビジネスステークホルダーとの交渉
        25.1.2　他のアーキテクトとの交渉
        25.1.3　開発者との交渉
    25.2　リーダーとしてのソフトウェアアーキテクト
        25.2.1　アーキテクチャの4 つのC
        25.2.2　プラグマティックでありながらもビジョナリーであること
        25.2.3　手本を示してチームをリードする
    25.3　開発チームに溶け込む
    25.4　まとめ

26章　アーキテクチャと交わるもの
    26.1　アーキテクチャと実装
        26.1.1　運用上の関心事
        26.1.2　構造上の整合性
        26.1.3　アーキテクチャの制約
    26.2　アーキテクチャとインフラストラクチャ
    26.3　アーキテクチャとデータトポロジー
        26.3.1　データベーストポロジー
        26.3.2　アーキテクチャ特性
        26.3.3　データ構造
        26.3.4　読み書きの優先順位
    26.4　アーキテクチャとエンジニアリングプラクティス
    26.5　アーキテクチャとチームトポロジー
    26.6　アーキテクチャとシステム統合
    26.7　アーキテクチャと全社標準
    26.8　アーキテクチャとビジネス環境
    26.9　アーキテクチャと生成AI
        26.9.1　生成AI をアーキテクチャに組み込む
        26.9.2　生成AI をアシスタントとして活用する
    26.10　まとめ

27章　ソフトウェアアーキテクチャの法則（再考）
    27.1　第一法則：ソフトウェアアーキテクチャはトレードオフがすべてだ
        27.1.1　共有ライブラリと共有サービス
        27.1.2　同期メッセージングと非同期メッセージング
        27.1.3　必然的帰結その一：トレードオフの見落とし
        27.1.4　必然的帰結その二：一度だけではできない
    27.2　第二法則：「どうやって」よりも「なぜ」の方がずっと重要だ
        27.2.1　コンテキスト無視アンチパターン
    27.3　極端な選択肢の間のどこか
    27.4　最後のアドバイス

付録A　議論用の質問リスト

参考文献
訳者あとがき
索引

コラム目次
    氷漬け原始人アンチパターン
    クラス以前：モジュールによる再利用
    名前衝突のない言語：Java 1.0
    結合度のメトリクスはなぜこんなに似た名前なのか？
    メトリクスの限界
    「非機能要件」という言葉の寿命
    ソフトウェアアーキテクチャにおける多くの曖昧さ
    アーキテクチャ・カタの起源
    設計とアーキテクチャとトレードオフ
    事例：ヴァーサ号
    パフォーマンスの多様な意味合い
    循環的複雑度
    循環的複雑度はどれくらいの値だと良いのか？
    ラテン語由来の技術用語の複数形
    ドメイン駆動設計における境界づけられたコンテキスト
    アーキテクチャスタイルはどこから来たのか？
    3層アーキテクチャ、言語設計、長期的な影響
    コンウェイの法則
    なぜサービスと呼ばれるものがこれほど多く存在しているのか？
    本当に？ 宣言的トランザクション？！
    強制的な不均質性
    直交結合
    ADR とコメント募集（RFC）
    制作物への不合理な愛着
    レイヤーを装飾的にではなく、意味的に使用する
    ホーソン効果
    ビジネス上の正当性が持つインパクト
    開発者のフロー状態
    歴史：Pets.com と弾力的なスケーリングが必要な理由
    なぜ素晴らしいものを持てないのか――トレードオフ！