タイトル	著者
Clean Architecture 達人に学ぶソフトウェアの構造と設計	Robert C. Martin

単一責任の原則や凝集性などのソフトウェア設計におけるプラクティスが広く述べられているなかで、 本書でより強く述べられているのは、安定度が高い要素に対して依存すべき という点。

具体のオブジェクトよりも抽象（インターフェース）に依存すべしであってり、(変更してもいいように)DBやフレームワークへの依存は避けるべきであったり、 適切に領域を切って変更が発生しやすい要素への依存を断ち切ることで、テストしやすくなり変更にも強くなると。

これを実装に落とせば Dependency Injection というデザインパターンになるが、本書の核はこの点だと思った。

一方、Clean Architectureとして知られている同心円の図自体を追い求めることは、本質的ではないように感じた。

WEBサービスの場合は、業務系アプリケーションとは異なりシステム上でのデータの受け渡しそのものが業務の実態であり、 同心円の中心の Enterprise Business Rules と Application Business Rules の区別がつきづらく、 かつ区別をつけたとしても、変更理由や頻度が近くなるように思われ、線引する意義が薄いように思う。

本文中にあったタクシー予約システムの例で、そのシステムを子猫引取システムにも転用する例があった。 乱暴に分類すれば、以下のような分類であろうか。

• Application Business Rules : 予約にまつわる業務プロセスのクラス群
• Enterprise Business Rules : タクシークラス / 子猫クラス

確かに、このような要望に対応するためには、共通部分と独自部分をIntefaceで区切って実装するのが良いと思うが、 果たしてこのような実装を最初から選ぶべきか？と考えると、正直難しい。

また、こちらの記事で、MySQLとMongoDBでDBを入れ替える実装を試みたが、実際のシステムではRDBMSとDocumentDBの入れ替えを考慮した設計なんて普通求められない。 ※ 上記の例の場合、TaskRepositoryとDBConnectionの２層でなく１層にし、テスト容易性を考慮してDBConnectionの実態とモックを分けられれば十分では？とも。

とはいえ、主題のメッセージである 安定度が高い要素に対して依存すべき 、という観点は厳守すべきで、 テスト容易性を担保しつつ開発を進めるべきという点は変わらない。

結局の所、この観点を守りながらソフトウェア開発をしていけば、 クリーンアーキテクチャに寄っていく という事であって、はじめから クリーンアーキテクチャで設計・実装する ということではないように思う。