クリーンアーキテクチャについて改めて学びたいと思い、ちょうど2ヶ月前に新版が出たので買って読んだ。
本書は、特定のフレームワークやプログラミング言語の実装方法を説明する本ではない。プログラムを構成する要素をどう組み立て、変化し続けるシステムをどう設計するかを扱った本である。プログラミングパラダイム、SOLID原則、コンポーネントの凝集性・結合、そしてアーキテクチャへと話が進んでいく。クリーンアーキテクチャという名前はよく聞くが、単に同心円状にレイヤーを描くための手法ではなく、依存をどう制御するかを考えるための原則なのだと理解できた。
システムを設計する上では、具体（詳細）と抽象を見極める必要がある。データベースやWeb、GUIは詳細であり、ビジネスルールのような抽象がそれらの詳細に振り回されるべきではない。データベースの製品やWebの技術、UIの作り方は時代によって移り変わっていく。一方で、システムが解決したい業務上のルールや価値は、それらよりも長く残るはずである。だからこそ、詳細は切り離され、どのようなデータベースやGUIにも対応できる構成にしておくべきだ。最上位のビジネスルールが、データベースがどのような構造でデータを保存しているかを知る必要はない。
これはハードウェアの世界にも転用できると感じた。ソフトウェア・ファームウェア・OS・ハードウェアのレイヤー間に抽象レイヤーを挟めば、最上位のソフトウェアは、特定のOSやハードウェアという詳細を意識せずに済む。詳細を完全になくすことはできないが、詳細が変わったときに、その影響がビジネスルールまで伝わらないようにすることはできる。変化を止めるのではなく、変化する場所を閉じ込めるという考え方が重要なのだと思う。
マイクロサービスのように、物理的にサービスを切り離すことで依存を剥がすテクニックもある。マイクロサービスはスケーラブルなシステムにする解決策としてもよく取り上げられる。ただ、物理的に切り離されていたとしても、共通のデータベースやサービスに依存している限り、間接的に依存していると言える。サービスの数を増やすこと自体が目的になると、依存関係はかえって見えづらくなるかもしれない。逆に、モノリスシステムでも設計次第では大規模システムとして耐えうるし、依存を制御することもできる。マイクロサービスかモノリスか、どのデータベースを選ぶかといった具体的な選択だけに目を向けるのではなく、その選択が本当に課題を解消するアプローチなのかを考える必要がある。小手先のテクニックに振り回されず、本質を見極めるための考え方として、クリーンアーキテクチャを捉え直せた。
クリーンアーキテクチャそのものよりも、変化する詳細から守るべきものは何か、システムとしてどうあるべきかを学べて非常に良かった。