『ソフトウェアアーキテクチャの基礎』
https://gyazo.com/a22b74ca3bbc567e5159b6a104fe0a5c
2022/3/8
ターゲットはソフトウェアアーキテクト、またはそれを目指す人
読む前の疑問点
どういう内容の本？
Clean Architecture本と同じような感じ？ではないか。
そういうものも紹介しつつ、あるあるのアーキテクチャも紹介する感じ？
1章を読んでみたが、微妙に読むタイミングが異なる気がしたmrsekut.icon 2022/9/4
今読むなら、章で気になったところつまみ読みするのが良さそう
通読するのに良さそうなタイミングは、チームがそこそこ大きくて、アーキテクチャの多様性がありうる場面でアーキテクチャを決定する時、とかだろうか
ということで、いったん中断するmrsekut.icon
はじめに：公理を疑う
1章 イントロダクション
なるほど感があるmrsekut.icon
社内政治との関わりも大きい
あまり、本書とは関係ないかもしれない感想だけどmrsekut.icon
1つの会社で働き続けると、アーキテクチャが似たようなものになりがちな気がする
プロダクトの規模、働く人の知識や得意分野、扱える言語の種類によって半固定的になる
第I部 基礎
2章 アーキテクチャ思考
2.1 アーキテクチャと設計
2.2 技術的な幅
2.3 トレードオフを分析する
2.4 ビジネスドライバーを理解する
2.5 アーキテクティングとコーディングのバランスを取る
3章 モジュール性
モジュールは、物理的な分離を意味せず、 論理的な分離のみを意味する。 この違いはときに重要だ。
この一文でのおかげで、こんがらがってたことが一部整理されたmrsekut.icon
凝集度、結合度、Abstractness, Instability
こういう指標があるよって紹介だけで、なぜ有用なのかとかはあまり書かれてない
モジュールの物理的表現であるコンポーネント
あ、そういうことなん！？mrsekut.icon
moduleは論理的なもので、componentは物理的なものってこと？
次のページに「マイクロサービスは、Componentを必要しないほど小さな場合がある」という文章があるが、「Componentがないコード」ってなに？
外部のライブラリ等に依存してないようなコードということ？
4.1 アーキテクチャ特性の（部分的な）リスト
4.1.1 アーキテクチャの運用特性
4.1.2 アーキテクチャの構造特性
4.1.3 アーキテクチャの横断的特性
4.2 トレードオフと少なくとも最悪でないアーキテクチャ
5章 アーキテクチャ特性を明らかにする
5.1 アーキテクチャ特性をドメインの関心事から捉える
5.2 要件からアーキテクチャ特性を抽出する
5.3 事例：シリコンサンドイッチ
5.3.1 明示的な特性
5.3.2 暗黙的な特性
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.2.1 事例：Going、Going、Gone
8章 コンポーネントベース思考
8.2 アーキテクトの役割
8.2.1 アーキテクチャの分割
8.2.2 事例：シリコンサンドイッチにおける分割
8.3 開発者の役割
8.4 コンポーネントを識別する流れ
8.4.1 初期コンポーネントを識別する
8.4.2 コンポーネントに要件を割り当てる
8.4.3 ロールや責務を分析する
8.4.4 アーキテクチャ特性を分析する
8.4.5 コンポーネントを再構成する
8.5 コンポーネントの粒度
8.6 コンポーネント設計
8.6.1 コンポーネントの発見
8.7 事例：「Going、Going、Gone」におけるコンポーネントの発見
8.8 アーキテクチャ量子再び：モノリシックアーキテクチャと分散アーキテクチャの選択
第II部 アーキテクチャスタイル
9章 基礎
II部の概要
II部で解説されるパターン、こういう区分けらしい
モノリシック
レイヤードアーキテクチャ ( 10章)
パイプラインアーキテクチャ (11章)
マイクロカーネルアーキテクチャ ( 12章 )
分散
サービスベースアーキテクチャ ( 13章)
イベント駆動アーキテクチャ ( 14章)
スペースベースアーキテクチャ ( 15章)
サービス指向アーキテクチャ (16章)
マイクロサービスアーキテクチャ ( 17章)
11.1 トポロジー
11.1.1 パイプ
11.1.2 フィルター
11.2 事例
11.3 アーキテクチャ特性の評価
12.1 トポロジー
12.1.1 コアシステム
12.1.2 プラグインコンポーネント
12.2 レジストリ
12.3 コントラクト
12.4 事例とユースケース
12.5 アーキテクチャ特性の評価
13.1 トポロジー
13.2 トポロジーの種類
13.3 サービスの設計と粒度
13.4 データベース分割
13.5 アーキテクチャ例
13.6 アーキテクチャ特性の評価
13.7 このアーキテクチャスタイルがふさわしいとき
14.4 非同期の能力
14.5 エラー処理
14.6 データロスの防止
14.7 ブロードキャスト能力
14.8 リクエスト・リプライ
14.9 リクエストベースとイベントベースの間を取る
14.10 ハイブリッドなイベント駆動アーキテクチャ
14.11 アーキテクチャ特性の評価
スペースベースアーキテクチャは、高いスケーラビリティ、弾力性、高い同時実行性といった問 題に対処することを目的に設計されたアーキテクチャスタイルだ。 このアーキテクチャスタイル は、同時接続ユーザー数が変動して予測できないようなアプリケーションにも有効だ。弾力的なス ケーラビリティをアーキテクチャ的に解決することは、データベースをスケールアウトさせようと したり、スケーラビリティのないアーキテクチャにキャッシュ技術を後付けしたりするよりも、良 いアプローチであることが多い。
15.1 一般的なトポロジー
15.1.1 処理ユニット
15.1.2 仮想ミドルウェア
15.1.3 データポンプ
15.1.4 データライター
15.1.5 データリーダー
15.2 データ衝突
15.3 クラウドとオンプレミス
15.4 レプリケーションキャッシュと分散キャッシュ
15.5 ニアキャッシュの考慮
15.6 実装例
15.6.1 コンサートチケット販売システム
15.6.2 オンラインオークションシステム
15.7 アーキテクチャ特性の評価
16.1 歴史と哲学
16.2 トポロジー
16.3 分類
16.3.1 ビジネスサービス
16.3.2 エンタープライズサービス
16.3.3 アプリケーションサービス
16.3.4 インフラストラクチャサービス
16.3.5 オーケストレーションエンジン
16.3.6 メッセージフロー
16.4 再利用...と結合
16.5 アーキテクチャ特性の評価
17.1 歴史
17.2 トポロジー
17.3 分散
17.4 境界づけられたコンテキスト
17.4.1 粒度
17.4.2 データ分離
17.5 API層
17.6 運用面での再利用
17.7 フロントエンド
17.8 通信
17.8.1 コレオグラフィとオーケストレーション
17.8.2 トランザクションとサーガ
17.9 アーキテクチャ特性の評価
17.10 参考文献
18章 適切なアーキテクチャスタイルを選ぶ
18.1 アーキテクチャにおけるトレンドの変遷
18.2 判断基準
18.3 モノリスの事例：シリコンサンドイッチ
18.3.1 モジュラーモノリス
18.3.2 マイクロカーネル
18.4 分散型のケーススタディ：Going、Going、Gone
19.1 アーキテクチャ決定に関するアンチパターン
19.1.1 資産防御アンチパターン
19.1.2 グラウンドホッグデーアンチパターン
19.1.3 メール駆動アーキテクチャアンチパターン
19.2 アーキテクチャ上重要なもの
19.3 アーキテクチャデシジョンレコード
19.3.1 基本構造
19.3.2 ADRを保存する
19.3.3 ドキュメントとしてのADR
19.3.4 標準のためにADRを用いる
19.3.5 事例
20章 アーキテクチャ上のリスクを分析する
20.1 リスクマトリックス
20.2 リスクアセスメント
20.3 リスクストーミング
20.3.1 特定
20.3.2 合意
20.3.3 軽減
20.4 ユーザーストーリーリスク分析
20.5 リスクストーミング例
20.5.1 可用性
20.5.2 弾力性
20.5.3 セキュリティ
21章 アーキテクチャの図解やプレゼンテーション
21.1 図解
21.1.1 ツール
21.1.2 標準ダイアグラム：UML、C4、ArchiMate
21.1.3 図解ガイドライン
21.2 プレゼンテーション
21.2.1 時間を操る
21.2.2 段階的な構築
21.2.3 インフォデッキとプレゼンテーション
21.2.4 スライドは物語の半分
21.2.5 不可視化
22章 効果的なチームにする
22.1 チーム境界
22.2 アーキテクトのパーソナリティ
22.2.1 コントロールフリーク
22.2.2 アームチェアアーキテクト
22.2.3 効果的なアーキテクト
22.3 どうやって管理する？
22.4 チームの警告サイン
22.5 チェックリストの活用
22.5.1 開発者のコード完成チェックリスト
22.5.2 ユニットテストと機能テストのためのチェックリスト
22.5.3 ソフトウェアリリースのためのチェックリスト
22.6 ガイダンスの提供
22.7 まとめ
23章 交渉とリーダーシップのスキル
23.1.1 ビジネスステークホルダーとの交渉
23.1.2 他のアーキテクトとの交渉
23.1.3 開発者との交渉
23.2 リーダーとしてのソフトウェアアーキテクト
23.2.1 アーキテクチャの4つのC
23.2.2 プラグマティックでありながらもビジョナリーであること
23.2.3 手本を示してチームをリードする
23.3 開発チームに溶け込む
23.4 まとめ
24章 キャリアパスを開く
24.1 20分ルール
24.2 パーソナルレーダーの開発
24.2.1 ThoughtWorksテクノロジーレーダー
24.2.2 オープンソースのビジュアライゼーションビット
24.3 ソーシャルメディアの使用
24.4 別れの挨拶
付録A 自己評価のためのチェックリスト
参考文献
訳者あとがき
索引