原著 : Fundamentals of software architecture : an engineering approach

著者 : Mark Richards、Neal Ford

訳 : 島田浩二

Amazon : https://amzn.to/3hZdOwH

ソフトウェア開発のエコシステムは動的な平衡状態 : 均衡が保たれつつ、長期的には動的

ソフトウェアアーキテクトのキャリアパスが定まっていない

ソフトウェアアーキテクチャ自体の定義が曖昧だし、変化が激しい

ソフトウェアアーキテクトの役割が広範

プロセスに関する問題がソフトウェアアーキテクチャの領域に入ってきている (プロセスはアーキテクチャの多くの面に影響)

それでもプロセスとエンジニアリングプラクティスは分けて考えるべき

ソフトウェア開発における予測や見積りの難しさは、未知の未知に起因

『進化的アーキテクチャ ―― 絶え間ない変化を支える』 では、アーキテクチャ適応度関数という考えを提案

DevOps はアーキテクチャの公理が見直されたことで登場

従来は運用を外部に委託していた会社が多く、アーキテクトが運用に対して防御的になっていた

運用上の能力をアーキテクチャ内部で扱えるように設計し、結果として複雑なアーキテクチャになっていた

近年は、アーキテクチャを運用と連携させ、設計を単純にし、運用メンバーに最適な対応を任せるように

アーキテクトと運用メンバーが組むことで、マイクロサービスが作られた

ソフトウェアアーキテクチャの法則

アーキテクトはドメインやビジネスの要件の定義に協力しつつ、アーキテクチャ特性の定義、発見、分析に責務を持つ

あらゆるアーキテクチャ特性を備えようとすると扱いにくい設計になってしまう

アーキテクチャをできるだけイテレーティブに設計すべき

アーキテクチャ特性を明らかにするのは、アーキテクチャ設計や既存アーキテクチャの正当性の判断のための最初の一歩

アーキテクチャ特性を明らかにするには、ドメインの関心を翻訳できる必要

ドメインのステークホルダーとアーキテクトの言葉の壁 → ドメインの関心事からアーキテクチャ特性への翻訳

ユーザー数から、スケーラビリティや弾力性を考慮

カスタマイズ性もひとつのアーキテクチャ特性

暗黙的なアーキテクチャ特性 : 可用性、信頼性など

アーキテクチャ特性について客観的な定義を持つべき (組織内での会話が円滑になる)

『進化的アーキテクチャ ―― 絶え間ない変化を支える』 で定義されたアーキテクチャ量子の概念

アーキテクトは、アーキテクチャを構成するコンポーネントを定義し、改良し、管理、統制する

コンポーネントは、アーキテクトが関わるソフトウェアシステム構成要素の中で (例外を除き) 最も小さいもの

アーキテクチャスタイルの重要な側面である最上位分割

技術による最上位分割 : レイヤードアーキテクチャなど

ドメインによる分割 : モジュラーモノリス、マイクロサービスアーキテクチャなど

『エリック・エヴァンスのドメイン駆動設計』 に触発されている

モノリシックアーキテクチャと分散アーキテクチャ

アーキテクチャスタイルとアーキテクチャパターン

各アーキテクチャスタイルの説明

アーキテクチャ決定が、アーキテクトに求められることのひとつ

アーキテクチャディシジョンレコード (アーキテクチャ決定記録文書)

リスクマトリクス、リスクアセスメント、リスクストーミング

本書の描画ツールは OmniGraffle (特定のツールを推奨しているわけではない)

標準ダイアグラム : Unified Modeling Language (UML)、C4 モデル図 (C4)、ArchiMate

文書とは違い、発表側が時間をコントロールする

2 つの情報チャネルがある (スライドと話者) ので、それらをうまく使う

アーキテクトは、アーキテクチャを実装する際の制約 (= 箱) を作る

境界がきついとフラストレーションがたまり、ゆるいと混乱を招く

ブルックスの法則 (= プロセスロス)、多元的無知、責任の分散

チェックリストを活用する

設計指針を用いてガイダンスを提供

アーキテクトは多くの人から異議を唱えられる

開発チームからも、他のアーキテクトからも、ステークホルダーからも

交渉とファシリテーションの能力が重要

交渉でも分割統治が使える

常に正当な理由を示すこと

象牙の塔のアーキテクトアンチパターン

リーダーとしてのソフトウェアアーキテクト

ソフトウェアアーキテクトのキャリアパスについて

パーソナルレーダーの開発

アーキテクトは技術のポートフォリオを金融のポートフォリオと同じように扱うべき

#書籍 #文献