クリーンアーキテクチャは依存関係を意識するのが大事だと思った

前置き

今回は「ちょうぜつソフトウェア設計入門――PHPで理解するオブジェクト指向の活用」という書籍の１章を読んで学んだこと、感じたことをまとめていきます

前提、ソフトウェアのアーキテクチャを考えるのって難しいし時間がかかりますよね。
いつもどのファイルをどこに置くべきか、どの処理をどのクラスに置くべきか、変に時間を使って悩んでしまうことがあります。
ちょっとでも悩む時間を減らすために、ちょっとずつクリーンアーキテクチャを紐解いていきたい(願望)

クリーンアーキテクチャの条件

書籍には、以下の条件を満たせばきれいな設計ができそうと書いてありました。

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

３つめの条件が重要で、不安定が安定に一方的に依存することでクリーンなアーキテクチャに近づくことができます。

不安定が安定に依存するとは

クリーンアーキテクチャにおける安定とは何のことでしょうか🤔
ぐらっぐらの土台の上にしっかり安定した建物を建てても、土台が崩れればその上の建物も崩れる。
それはそう！
ただそれは現実世界の話。
システムの場合、変更頻度が低いことが安定していると言えるようです。

例えば業務ロジック、UIの仕様を比較した場合、UIの仕様の方が変更頻度が高そうですよね。
UIの変更が業務ロジックに影響を与えてしまうのは、安定が不安定に依存していることになります。
そのため業務ロジックはUIに依存せず、UIが業務ロジックに依存する形が望ましいです。

ただ、既存のコードをもとに「変更頻度が低いかどうか？」で考えようとすると難しいこともあるかもしれません。
依存関係がきれいになっていない状態だと、本来は安定すべきところも不安定になっている可能性もあるためです。
その場合、安定させたいもの、変わらないものを中心に追いやることで変更頻度を減らしていくという考え方もできます。
コードの変更頻度ではなく、仕様や要件の変更頻度で考えましょう。

また業務ロジックは比較的安定しているといっても、移り変わりの激しい業界だと業務ロジックの変動も激しい場合もあるかもしれません。
業務ロジックの中でも、核となるものとそうでないもので分けて考えると、安定性のあるロジックとそうでないロジックが見えてくるかもしれないです。(業界ルールは安定しやすく、企業独自のルールは安定しにくい、など)

「具象クラスではなくinterfaceに依存すべき」というのも考え方は同じで、具体の実装内容が変更されてもinterfaceは変わらないため安定に依存していると言えます👍

感想

何がどの層で、どこに置くべきか？よりも、何がどこに依存しているか？を考えるのが大事だな〜〜〜と改めて思いました。
ディレクトリの名前どうする？(　ﾟдﾟ)とか、本質的じゃないことに悩むのはもうやめにしよう。

参考

[1] 和田 卓人. 『ちょうぜつソフトウェア設計入門』. 技術評論社, 2022年.