ソフトウェアアーキテクチャの基礎
↓の読書メモ
1章 イントロダクション
アーキテクチャの構成要素
- システムの構造
- アーキテクチャ特性
- アーキテクチャ決定
- 設計指針
システムの構造
システムを実装するアーキテクチャスタイルの種類を指す
ex) マイクロサービス，レイヤード，マイクロカーネルなど
アーキテクチャ特性
システムの成功基準を定めるもの
システムの機能に関する知識を必要とせずに理解できるもの
ex) Availability, Reliability, Testability 等
アーキテクチャ決定
システムをどのように構築すべきかのルールを定めるもの
システムの制約を形作り，何がゆるされて何が許されないかに関する開発チームの指針になる
ex) アーキテクトはレイヤードアーキテクチャ上でビジネス層とサービス層のみがDBに直接アクセスできるというアーキテクチャ決定を行うことでプレゼンテーション層が直接DBを呼び出すことができる
設計指針
アーキテクチャ決定とは異なり，堅苦しいルールではなくガイドラインである
望ましいアプローチにたいする指針を提供するもの
ex) 非同期メッセージングを利用してパフォーマンスを向上させるべきである
アーキテクトへの期待
- アーキテクチャ決定を下す
- アーキテクチャを継続的に分析する
- 最新のトレンドを把握し続ける
- 決定の順守を徹底する
- 多様なものに触れ経験している
- 事業のドメイン知識を持っている
- 対人すきるを持っている
2章 アーキテクチャ思考
アーキテクチャと設計
アーキテクチャを機能させるにはアーキテクトと開発チームの間に存在する仮想的・物理的な壁を取り払い，双方向の関係を築く必要がある
アーキテクチャはプロジェクトのイテレーションやフェーズと共に変化するのが不可欠
アーキテクチャと設計の間に明確な境界線はない，どちらもソフトウェアプロジェクトを構成するものであり，両者が常に同期されてなければならない
技術的な幅
開発者は技術的な深さを持たなければならないが，アーキテクトは技術的な幅が要求される
個人の知識はいかの3つに分類できる
- わかっていること
- わかっていないとわかっていること
- わかっていないとわかっていないこと
わかっていることの大きさがその人の技術的な深さとなる
アーキテクトは問題に対する解決策を多く持たなければならないため，わかっていないとわかっていることが重要になってくる
トレードオフを分析する
アーキテクチャはすべてがトレードオフである
様々な要因の上で適するアーキテクチャは定まる
もたらされるプラスの側面とマイナスの側面の両者に目を向け，分析し最適解を模索する
Discussion