Open2022/11/03にコメント追加7

ソフトウェアアーキテクチャの基礎メモ

元ネタ

ソフトウェアアーキテクチャは建築構造と同様に、内外からシステムに作用する力に対して、システムが崩壊しないように保つためのもの。内外から働く作用を考慮しながらシステムをヘルシーに進化させ続けるためのものとも言えるだろうか。

そしてこの目的を達成するために備わっていることが期待される性質がアーキテクチャ特性である。アーキテクチャ特性の候補となるのが、-ilityである。

など

本書におけるソフトウェアアーキテクチャとは、アーキテクチャ特性を備えるために必要なもので、構造になったものと構造にならなかったもので構成される。

クリーンアーキテクチャのような「xxアーキテクチャ」はアーキテクチャパターン (アーキテクチャスタイル)であり、アーキテクチャそのものではない。構造にならなかったもの、に近い。

例えば、事業として「市場への投入速度」が求められるような開発の場合、以下のような優先すべきアーキテクチャ特性が考えられる (アジリティは複合的な特性として捉えている）。

前提としてアーキテクチャ特性の全部入りのようなものはできない:

なので、与えられた制約条件、環境下で備えなければならないアーキテクチャ特性を定めることが重要となる。

アーキテクチャは様々なものに影響を受ける、与えるためそれらを考慮して決めていく必要がある。

開発チームの能力、スキル、知識
- 開発チームがシステムを構築するまで構造は実際には存在しない
- 作らないとアーキテクチャ特性を満たしているか、計測、評価できない
- 開発チームが作れない構造では意味がない
ソフトウェア開発エコシステムの変化
- 構造は何かしらの技術を用いて実現される
- ソフトウェア開発エコシステムエコシステムは絶えず変化している
  - 技術の変化はアーキテクチャ特性の実現容易性などに影響を与える
  - ex. Dockerのコンテナ技術
- 現在エコシステムがどう変化しているか、この先どう変化していくかを考える必要がある
組織のコミュニケーション構造
- システムを設計する組織は、そのコミュニケーション構造をそっくり真似た構造の設計を生み出してしまう (コンウェイの法則)
データ
- データは貴重なもので、システム自体よりも寿命が長い
  - どこにどのように格納するのかが重要
- 分析データの扱いはアーキテクチャ特性に影響を与える
  - ex. パフォーマンス、セキュリティ

影響を与えるものは大きく以下のようなパターンがあり、事前にすべては把握できない。

ソフトウェアアーキテクチャはGoogleで答えが見つかるような類のものではない。そしてアーキテクチャには正解も不正解もなく、ただトレードオフが存在するだけのものである。

アーキテクティングの指針は

「必要最小限のアーキテクチャ」を心がける。そしてそれをイテレーティブに育てていくイメージ。

責任を持てる限りにおいて判断、意思決定を遅らせる、ここぞという時 (以下の時点)で決める
- 最終責任時点: 決定を下し損ねると、重要な代替案がなくなる時点
- 最大責任時点: 決定することで、最も前向きな影響を与える時点
アーキテクチャ特性に直接影響しない設計判断や具体的な実現方法は開発チームに委ねる
- 開発チームと一緒に実現していく
開発や運用からフィードバックを得ていく
- 未知なものが減っていく

アーキテクチャを見直し続ける。

アーキテクチャが経年劣化しないように、継続的に見直し続けることが重要。

これはまさに建築物のリフォーム、リノベーションの感覚に近い。