TL;DR
Robert C. Martin による、各ソフトウェアモジュールが変更される理由は 1 つだけであるべきだという原則。
なぜ必要か
異なる人が関心を持つコードを混ぜると、ある人のための変更が、別の人のための機能を壊す。手を動かしてわかるクリーンアーキテクチャ では、ドメイン層が永続化の関心事まで扱うと、ドメイン層に影響を与えずに永続化層を変更するのが難しくなるとしている。
仕組み
Martin のブログによると、この原則は人についての原則である。変更の理由は人、または 1 つの業務機能を代表する密接な人の集まりから生まれる。バグ修正やリファクタリングはプログラマの責任であって、プログラムが変わる理由ではない。
同じ理由で変わるものは集め、違う理由で変わるものは分ける。Martin はこれを凝集度と結合度の別の言い方だとしている。Parnas の情報隠蔽や、Dijkstra の関心の分離の考え方を受け継いでいる。
例
Martin のブログでは、calculatePay、save、reportHours を持つ Employee クラスを例にしている。給与計算は CFO、労働時間のレポートは COO、永続化は CTO が責任を持つので、この 3 つは別の理由で変わる。
注意点
「1 つの仕事」が何かは人間の直感に頼るので、自動では判断できない。また、A Philosophy of Software Design はクラスを小さく分けすぎることをClassitisとして批判しているが、大きすぎるクラスも問題なので、両者は真逆というわけではない。