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

メモです。読み直して理解が変わったりしたら更新していく

1章　イントロダクション

• ソフトウェアアーキテクチャの定義
  • 構造（アーキテクチャスタイルの種類 (マイクロサービス、レイヤード、など)）
  • アーキテクチャ特性（「イリティ (-ility)」）
  • アーキテクチャ決定（アクセス可能性に関してなどの "ルール"）
  • 設計指針（選択を助けるおおまかな "ガイドライン"・方針）
• ソフトウェアアーキテクチャの法則
  • 第一法則「ソフトウェアアーキテクチャはトレードオフがすべて」
    • この後何度も出てくる
  • 第二法則「「どうやって」よりも「なぜ」の方がずっと重要だ」
    • よくわからない

2章　アーキテクチャ思考

• アーキテクトと開発者、アーキテクチャと設計、を分けて考えている
• 開発者は技術的な深さ（専門性）を要する、アーキテクトは技術的な幅を要する。それぞれ役割によって逆は捨てなくちゃならなかったりする
• アーキテクトはその幅によって複数のソリューションを提案しなくちゃならない。複数のソリューションのメリットとトレードオフを理解して、判断する
• 「アーキテクチャには正解も不正解もない。あるのはトレードオフだけだ。」
• アーキテクトも現場感を忘れないようにコードを書くとよい
• その際、プロジェクトのクリティカルパスにあるコードの所有権を握りチームのボトルネックになるのを避ける、というのが書いてあった。たしかに。

3章　モジュール性

• 凝集度、結合度、抽象度、不安定度、主系列からの距離、コナーセンス
• これらのモジュール性を計測してメトリクスを取りたい。けど、構造からしかわからないので「なぜ」が反映できなかったりして精度が低いこともある。解釈が必要
• モジュールを分割するかどうかも「場合による」
• 求心性結合、遠心性結合がよくわかってない
• XX的凝集、むずかしい
  • わかりやすいスライド: https://speakerdeck.com/sonatard/coheision-coupling
  • 関数で例えてるけど概念は理解しやすい
  • 単機能の関数が COOL だと思ってたのは、機能的凝集（最良）だからだった
  • 論理的凝集な関数をユースケースごとに分けて時間的凝集 (or 手続的凝集) な関数にして、さらに内容も機能的凝集な関数に分けていくやつ、前にやったことあった。こういうリファクタリング（関数をバラすみたいな）はテストが難しかった。
• コナーセンス
  • 各コナーセンスの理解がむずかしい。部分的にはわかったけど例がほしい
  • 凝集の種類があるみたくコナーセンスにも種類があって、よさげなのと悪めなのとがある
  • 性質として、強さと位置関係がある。強いほうが厳しい合意が必要で悪めで、弱いほうが優しい合意でよくてよさげ。遠くて強いのはよくなくて、近くて強いのは別にいい（複雑さを狭いところに押し込めている的な）
• 「これが良いコードでこっちは悪いコードだ」とふんわり思ってたのが言語化された章でした