クリーンアーキテクチャを読んだ

クリーンアーキテクチャを（2ヶ月前くらいに）読んだので、内容の復習も兼ねて自分なりにまとめてみます。

振る舞いの価値と構造の価値

まず、ソフトウェアの持つ価値には振る舞いの価値と構造の価値の２種類があります。 振る舞いの価値とは、いわゆる機能要件のことであり、構造の価値とは、振る舞いの変更のしやすさ、つまり内部品質や変更容易性と表現される非機能要件を指す、と理解しています。 ビジネスエキスパートにとって、後者の価値を評価することは難しいため、どうしても前者の価値が優先されてしまいがちです。 その結果、昨今話題になっている技術的負債が蓄積してしまうという構造があるかと思います。

すべてのソフトウェアシステムは、ステークホルダーに2つの異なる価値を提供する。それは「振る舞い」と「構造」だ。ソフトウェア開発者には、この2つの価値を維持する責任がある。残念ながら、片方だけにフォーカスすることが多く、もう片方が無視されてしまっている。さらに残念なことに、2つのうち価値の低いほうにフォーカスすることが多く、最終的にソフトウェアシステムの価値がゼロになってしまうこともある。

本書では、構造の価値（=アーキテクチャ）を重要視してソフトウェアを作ることはソフトウェアエンジニアの責務であると書かれています。

ソフトウェア開発者のジレンマは、ビジネスマネージャーがアーキテクチャの重要性を評価できないことである。そのためにソフトウェア開発者が雇われている。したがって、ソフトウェア開発チームには、機能の緊急性よりもアーキテクチャの重要性を強く主張する責任が求められる。

ところで、構造の価値を持ったソフトウェアとはどのようなソフトウェアでしょうか。 それは、超ざっくりいうと重要なものと重要でないものの間に境界線が引かれたアーキテクチャを採用したソフトウェアです。

境界線は「重要なもの」と「重要ではないもの」の間に引く。GUIはビジネスルールにとって重要ではないので、その間に境界線を引く。データベースはGUIにとって重要ではないので、その間に境界線を引く。データベースはビジネスルールにとって重要ではないので、その間に境界線を引く。

その重要なものと重要でないものの間に境界線が引かれたアーキテクチャこそ、クリーンアーキテクチャです。

クリーンアーキテクチャ

これは有名なクリーアーキテクチャ（の一例）の図です。

この図では、重要でないもの（UI, DBなど）は外側に、重要なもの（Entitys*1）内側に配置されています。 この円には「ソースコードの依存性は、内側（上位レベルの方針）だけに向かっていなければならない」というルールがあり、重要なものと重要でないものにしっかりと境界線が引かれています。

一点注意点としては、この図はあくまでクリーンアーキテクチャの一例であり、クリーンアーキテクチャの実装がすべてこの図のとおりになるわけではないということです。 円の数などが異なっていたとしても、依存の方向のルールを満たしていれば、それはクリーンアキテクチャーです。 したがって、ヘキサゴナルアーキテクチャや軽量DDDもクリーンアーキテクチャの一種と言えるかと思います。

図221の円は、概要を示したものである。したがって、この4つ以外にも必要なものはあるだろう。この4つ以外は認めないというルールはない。ただし、依存性のルールは常に適用される。ソースコードの依存性は常に内側に向けるべきだ。

終わりに

本書の構成は、ざっくりと以下のようになっています。

1. 構造の価値を軽視することの問題提起
2. プログラムの設計原則（オブジェクト指向、関数型プログラミングなど）
3. クリーンアーキテクチャ

「2.プログラムの設計原則」は分量がそこそこあり、クリーンアーキテクチャだけでなく、様々な設計原則などを学ぶことができます。 個人的には勉強になってよかったですが、これは、本書を先頭から読んでいくとなかなかクリーンアーキテクチャにたどり着かないということでもあります。 なので、前半部分をすっとばして後半のクリーンアーキテクチャの部分を先に読む、というのも本書の読み方のひとつかもしれません。（「クリーンアーキテクチャを学びたい」という動機で本書を読む人がほとんどだと思うので）

*1:いわゆるビジネスルールやビジネスデータを扱うクラスたち