ソフトウェア・アーキテクチャ・ハードパーツを読みたい
タイトルどおり、まだ読んでませんが、アーキテクトに関わっているので触りのところだけ読んでも面白そう。
本書ですが、ソフトウェア・アーキテクチャの基礎がベースになっています。
「ソフトウェア・アーキテクチャの基礎」を読んでいないといけないわけではなく、どちらかというと入門編、本書は実践編というような位置づけだという感じだと思います。
ざっくりいうと
ソフトウェアアーキテクチャは堅い（ハード）
- ソフトウェアアーキテクチャとは、ソフトウェアのソフトな部分の土台となるハードな部分
- ソフトウェアアーキテクチャとは後から変更するのが難しいお部分のことである。
ソフトウェアアーキテクチャ上の決定は困難（ハード）
- アーキテクトが直面するのは事業や組織的な環境に長期的に影響を与え、相互にも影響を与え合う困難な問題
- アーキテクチャとは、Googleで答えを見つけられないものだ
ソフトウェア・アーキテクチャーの第一法則
ソフトウェアアーキテクチャはトレードオフがすべて
”アーキテクチャのあらゆる問いに共通する答えは「場合による」のだ。
答えはデプロイ環境やビジネスドライバー、企業文化、予算、期間、開発者のスキルセットその他の多くの要因に依存する。環境や状況、問題点はそれぞれに異なるものだ。だからアーキテクチャは難しい。”
本書の概要
１つの具体的なコンテキストに沿って、アーキテクチャの議論をすすめる作りになっている。
具体的なコンテキスト
Sysops Squadサーガと呼ばれる具体的なモノリシックなシステムを分散的アーキテクチャへ移行する架空の物語
問題を多く抱えたレガシーで大規模なモノリシックなシステムの問題をどう解決するか？
後から変えるのが難しい硬い部分（ハードパーツ）をどう変えていくか
→モノリシックなシステムをどう分解していくか
決定するのが難しい問題（ハードパーツ）をどう決めていくか？
→分散システムで直面する難しい問題をどう決定していくか？
各章の大きな分類
モノリシックなシステムをどう分解するか？
2章 ソフトウェアアーキテクチャにおける結合の見つけ方
3章 ソフトぅエアアーキテクチャのモジュール化
4章 アーキテクチャの分解
5章 コンポーネントベース分解パターン
6章 業務データの分解
7章 サービスの粒度
分散システムの実現で直面するさまざまな力とトレードオフ
8章 再利用パターン
9章 データの所有権と分散トランザクション
10章 分散データアクセス
11章 分散ワークフローの管理
12章 トランザクショナルサーガ
13章 コントラクト
14章 分析データの管理
モノリシックなシステムをどう分解するか？
エンジニアの会話
アディソン オースティン：「アプリケーションが大きすぎてどこから手を付けいいかわかりません！」
ローガン：「アプリケーション全体を捉えた上で、戦術的フォークかコンポーネントベース分解を適用するのがよいやり方です。」
アディソン オースティン：「私達はどちらを使えばいいのでしょうか？」
モノリシックアプリケーションの分解アプローチ
戦術的フォーク
コードベースをコピーして別サービスを作り、不要な部分を削除することでモノリシックアプリケーションを分解する。
コンポーネントベース分解
正当方なやりかた。モノリシックなシステムを機能ごとに分解してサービスを構築しなおす。
ADR アーキテクチャ・デジジョン・レコード
どのようにアーキテクチャが決定されていった履歴を残すことで、どんな思想や条件、トレードオフなどで、設計が決まったか？などを記録。
モノリシックなシステムをどう分解するか？ (2章から７章）
コード的アプローチ
- モノリスからの分解アプローチ
- 戦術的フォーク
- コンポーネント分解
データ的アップローチ
- データベースを分解する５段階のプロセス
分散システムで直面する難題を決定していく際の難しさ (８章から14章）
”アーキテクトが直面する最も困難な課題の一つは、分散アーキテクチャに作用するさまざまな力とトレードオフを解きほぐすことだ”
”ソフトウェアアーキテクチャはさまざまな力が相互作用し合う多次元的な問題を生み出す。トレードオフ分析を行うには、まずトレードオフの関係にある力を把握しなければならない。”
分散システムの実現で直面するさまざまな力とトレードオフ
- サービスの適切な粒度をどう見つけるか？
- データ所有権をどう割り当てるか？
- ワークフローをどう実現するのか
- サービス間通信の方式をどうするのか？
- 共通的なコードをどう扱うか？
- 所有していないデータにどうアクセスするのか？
- データ整合性をどう確保するのか？
サービスの粒度
エンジニアの会話
テイレン：「ドメインサービスを小さなサービスに分解したほうがいいのでは？ マイクロサービスとしては粗すぎる」
ローガン：「すべてのサービスをマイクロにしようとするのは勝手ですよ。サービスを小さくしたい理由はなんですか？」
テイレン：「単一責任の原則ですよ」
ローガン「単一の責任が何を指すかは主観的なものです。サービスの粒度を正しく把握するには、粒度分解要因と粒度結合要因を使ってトレードオフを客観的に分析し、サービスを分割するかどうかの確固たる根拠を形成するのが重要です。」
粒度分解要因
どのような場合にサービスを小さく分解することを検討すべきか？
- サービスの範囲と機能
- コード変動率
- スケーラビリティとスループット
- 拡張性
- 耐障害性
- セキュリティ
粒度結合要因
- データベーストランザクション
- ワークフローとコレオグラフィ
- 共有コード
- データ関係
触りとしてはここまでなのですが、実際の現場でもどんな粒度でサービスを分解するかは非常に難しい問題です。
こういった分析要素として、まとめるというのは非常にわかりやすいと思います。
ぜひ、読もうと思います（苦笑