ちょうぜつソフトウェア設計入門を読んで

「アーキテクチャ」という言葉自体は何をどこに配置すれば良いかの決め事だが「クリーンアーキテクチャ」という言葉は少しニュアンスが違う

ことソフトウェアにおいては自分らで課題解決のためにどういう設計にしていこうかを考えなければならず、結局のところクリーンアーキテクチャとはその設計を最小労力で維持するコツを一般化すること

この本はそれを目指すためにどうしていくべきか、をオブジェクト指向をもとに考察していくもの

アーキテクチャの良し悪しはプログラムの動作に直接貢献しません

アーキテクチャは、ソフトウェアそのもののパフォーマンスではなく、ソフトウェアを開発するパフォーマンスを向上させます

これは刺さる
良いアーキテクチャとは？
悪いアーキテクチャとは？

• アーキテクチャが悪いとどうなるのか？
  • まとまりが悪くなって変更箇所が多くなる
  • 同じまとまりに意味が異なるものが混ざる
• コード自体が汚いならいいんだよ、それだけなら
• アーキテクチャは整理整頓の手段（かな？）

• モジュールをいかにきれいに作っていくか
  • 関心の分離は重要
  • 凝集度への意識
    • 凝集度が高い=無関係なものが集まっていない（←この意識が大事）

https://e-words.jp/w/モジュール.html

https://ja.wikipedia.org/wiki/モジュール

• ソフトウェアにおいてモジュールは必ず何かを繋がっている
• 繋がり=依存
• 依存の向きが重要
• 「自身に直接影響する」のか「依存するということに影響する」のか、どっちがマシか？
• 疎結合は結合が疎いと書くので結合自体はあるよ（なかったらただのゴミ）

オブジェクト指向を用いて解決したい設計課題は、主にこの依存との結合にまつわる問題

• ではどうすれば良いモジュールを作れるか
  • 安定度（コードの変わりにくさ） を意識する
• 安定度とはいわゆるstableバージョンのニュアンス
• 安定度が高い、低いとはどういう状態か？
  • 実際に測るのむずいよねー←わかる

人間的な理由によるこの本質か非本質かによる安定度が、実際にコード変更としてあらわれる安定度の分布と一致するのが、よいアーキテクチャに共通する特徴

自分の理解が追いついていない

• 例えばドメインモデルの変更って本質になると思うけど、ここの変更が少なければ安定している、と捉えて良いのかな
• 後から、やっぱこれも、って感じになるが現場では往々にしてあると思うけどそうなると安定していない、になっちゃう気がする
• その時その時を見るのではなくある期間で見ていくことになるのか
• これがstableバージョンってニュアンスの意味（？）
• 変更頻度が高いモジュールに依存しない、は感覚的には難しい気はする

クリーンな状態とは次を満たす状態

1. ひとつの関心がひとつの箇所に閉じている
2. 利用する／されるの関係箇所を可能なかぎり減らす
3. できるだけ変更頻度の高い事情に依存しない

クリーンアーキテクチャは特に3に着目している

プログラミング言語の文法と標準ライブラリ以外の何にも依存しないように記述します

phpならPOPOとして記述しろってことだけど、例えば日付に関する属性はCarbonライブラリではなくビルトインのDateTimeクラスを使えと
ライブラリに依存している=安定していないだけど、どこまでの安定度を求めるのかはチームで決めて良いように思うんだけどなぁ

やっぱ1はダメなんだろうか

// 1
class User
{
  public function __construct(Carbon\CarbonImmutable $birthDay) {}
}

// 2
class User
{		
  public function __construct(DateTime $birthDay) {}
}

• ドメインモデルは普遍的に存在する本質
• 仕様変更=ユーザーが操作したいことなのでそういったものを排除し共通したものを残す