ソフトウェアアーキテクチャの基礎（オライリー出版）

広い視野で考える必要があり、長期的な企業の事業と関係するソフトウェアアーキテクトという職業。
日本には相応スキルを持つ企業が存在しないが、米国のテックリード企業（Microsoft, Google etc…）のコアなレベルの人たちだと思っている。

（日本って、外国で作られたサービス、外国で作られた言語、そしてそのフレームワークを使うだけで、何故かマウント取りたがる人が多いから…テックリード企業は一生出てこないと思う。）

第1章では「ソフトウェアアーキテクチャ」の定義が曖昧であることから、マインドマップに落とし込むことから始める。
…で、この4つで分類。

• アーキテクチャ特性
• （システムの）構造
• アーキテクチャ決定
• 設計指針

アーキテクチャの特性を継続的に評価するなど、アーキテクトが具体的に何をしていくか、他には社内の政治についても記述されている。

ソフトウェア技術は日々進化するため、同じやり方が良い訳ではない。
広く浅くで最新技術に追従しつつ、最新の開発プロセスなど常に把握できるくらいの人でなければ務まらない。

第2章ではアーキテクチャの定義とトレードオフについて記述されている。
すべてについて最良を目指すと、複雑化し破綻するという話。

第3章ではモジュール性の定義と計測について記述されている。
凝集度については様々な相互作用について記載されている。
例えば、時間的なものやデータベースなどを介するもの。

第4章ではアーキテクチャ特性の要素について記述されている。
非機能要件と呼ばれる領域。

まあ、英語でも Non-functional requirement と表現されているので、非機能要件が一般的に使われていることは分かる。
著者が好んでいない呼び方らしいこともあり、アーキテクチャ特性が文中で用いられる。

Non-functional requirement – Wikipedia

（管理人もアーキテクチャ特性の方がわかりやすいと思う。非機能要件と書くと、重要ではないものに見える。）

第5章ではアーキテクチャ特性について明示的なものや暗黙的なものが記載されている。

第6章ではアーキテクチャ特性の計測について記載されている。コードについてはツールの紹介もある。
どうやって継続的に評価していくかが鍵となる。

10章～17章にアーキテクチャパターンとその評価が記載されている。
ここは辞書的に使うのが良い。

…この本、章が多い。
ページ数は400ページ弱ってところなので、多くはない。
多くはないが、読んで理解するのには時間がかかる。