「〇〇〇でクリーンアーキテクチャ実装した！」

そんな言葉を聞くたびに、僕はふと思う。

おー、「クリーンアーキテクチャ完全に理解した！」んですねわかります。

"Clean Architecture" という本はアーキテクチャの原理原則を丁寧に示したとても良い本で、著者の Uncle Bob はスゴい人だと思う。この本だけでもスゴさは分かる。例えば、"第5章オブジェクト指向プログラミング" における、オブジェクト指向を取り入れたプログラミング言語が、C言語では完璧に実現できていたカプセル化を、むしろ弱体化させてしまっているという話などは、実は僕自身、今まで発想だにしなかった話なので、正直、魂が震えた。

具体的には、C++ではクラスの宣言（ヘッダファイル）と実装が分かれたことで、クラスの内部構造の一部が物理的に外部に晒される設計になりやすくなった、という指摘だ。このレベルで理解すると、たとえばC#のinterfaceのメンバーにアクセス修飾子を書かない理由も自然に腹落ちしてくる。

若い読者にとっては、逆にこのあたりが一段とハードル高くなってるかも（笑）

そして例えば第2章には、「ソフトウェア開発者もステークスホルダーである」「常に闘争である」 という言葉がある。

"Clean Architecture" には、このような、僕の被雇用者としての立場を不安定にしかねないような、けれどもプロフェッショナルとしての心構えをブラッシュアップさせるような、ソフトウェアクラフトマンシップ的なポエムも随所に散りばめられている。

本記事は次の書籍をもとに書いています。（以下、「本書」）
Clean Architecture 達人に学ぶソフトウェアの構造と設計初版
Robert C.Martin (著), 角征典 (翻訳), 高木正弘 (翻訳)

一番大事なパート?

訳者あとがき

本書を理解するうえで、一番大事なパートは、じつは、「訳者あとがき」 ではないかと思う。原典を深く読み込んだ訳者が、読者にこっそりと注意事項を書いてくれているように思えるからである。

訳者あとがきにこう書かれている（太字は本記事筆者による）：

フレームワークから着手しないことが本当に正しいことなのか、私にはまだよくわからない。本書で紹介されている例は、いずれも現代的なアプリの話ではない。

意訳: そのままじゃ現代のアプリには通用しないかもね！とくにフレームワーク関係とか！

[略]、それでも 「時代を超越した不変のルール」が存在するとして、著者はいつまでも原理・原則に忠実であろうとする。

意訳: この本で大事なのは「原理・原則」だよ！むしろそれ以外のところはいろいろ許して！

本書で提唱されている 「Clean Archtecture」 については、すでに著者本人がブログや講演などで情報発信していることもあり、見よう見まねでアーキテクチャの「同心円」を実装している例が数多くみられる。

意訳: 本質（原理・原則）を理解しないまま、同心円の図だけ真似するのはアンチパターンだよ！

だが、著者のように原理・原則に忠実であるためにも、まずは本書に目を通してもらいたい。そして、著者と対話しながら、自らのアーキテクチャをクリーンにしてもらえれば幸いだ。

意訳: 本質を理解した上で、 （あたかも著者と対話でもするように、この本をスタートラインにして、）きちっと考え、自分の関わっているアーキテクチャをクリーンにしてみてね！

訳者あとがきに書いてほしかったこと

訳者としてのポジションもあると思うので、これを「訳者あとがき」に書くのは難しいのかもしれない。実際の「訳者あとがき」も、十分良心的だと思う。でも、僕が訳者だとしたら、次の節を「訳者あとがき」に書いておきたくなるかもしれない。

「Clean Architecture」という言葉自体も、英語としては単に「きれいな設計構造」 という意味しか持たない。特別な手法や流派を指すものではなく、「きれいに整理されたアーキテクチャ」くらいのニュアンスで読める。
日本の読者諸氏においても、「クリーンアーキテクチャ」というカタカナ語を、何か確立された技法や様式のように受け取ることのないよう、ご留意いただきたい。特に、同心円の図だけを見て「これがクリーンアーキテクチャだ！」と思い込んでしまう罠にはぜひ嵌らないでほしい。

つまり、僕が主張したいのは、

本書は、「特定のアーキテクチャ様式を提示するものではない」。クリーンアーキテクチャという言葉は、設計の原則や考え方を示すための便宜的な表現にすぎない。
- 特に第22章、「クリーンアーキテクチャ」という章の、例の「同心円の図」には要注意！（笑）

ということ。

「クリーンアーキテクチャ」という章

本書自体のアーキテクチャ（笑）

なぜこの章が「罠」かというと、adwdさんという方がブログにも書かれていることでもあるけど、「クリーンアーキテクチャ」という厚い本（30章を超え、付録もある）に「クリーンアーキテクチャ」という章が含まれていて、そこにキャッチーな同心円（笑）が載っているから。これでは「完全に理解」されてしまうのも仕方のないことのように思える。

しかし、本書にきちんと目を通せば、「クリーンアーキテクチャ」という章も、他の章と変わらず、技術的な原理・原則・クラフトマンシップポエムが散りばめられた単なるひとつの章であり、この本自体の結論となるような章ではないことがわかる。

※ この章のタイトルだけでも「整理整頓（されたアーキテクチャ）」とか、「（コンパイル時の）依存性のルール」くらいに訳す、というのはさすがに無理かw

もちろん、同心円の図も、「整理整頓されたアーキテクチャを特定の観点からみるとこんな感じ」というような、ざっくりイメージ（日本ではポンチ絵といいますね笑）くらいのものであることも把握できる。

なぜなら、他の章では触れられている（＝クリーンアーキテクチャという思想の一部である）ものの、この章には盛り込まれていない事柄が結構ある、から。

「クリーンアーキテクチャ」という章に書かれていないこと

一例を挙げると、OCP (Open-Closed Principle: 開放/閉鎖原則) について。

ソフトウェアの拡張性を考える上では非常に重要な原則であり、本書でも（第8章）でしっかり触れられている。しかし、「クリーンアーキテクチャ」という章（同心円の図が登場する章）では、依存関係のルールとの関連において、OCPをどう扱うべきかという観点は直接語られていない。

さらに、OCPを具体的に実現する設計パターンであるプラグインアーキテクチャ（第5章、第17章）との関連性も、図やアーキテクチャ層の説明とは明示的に結びつけられていない。

（例えば、Visual StudioのプラグインであるResharperを考えたとき、ResharperのEntityやUseCase層はVisual Studio本体のどのレイヤーに依存すべきか？──このような実践的な観点は本章からは読み取れない。）

だから、「クリーンアーキテクチャ」という章だけでは、クリーンアーキテクチャを完全に理解した()レベルにしか なれない。

フレームワークを一番外側（詳細）扱いは、現代では無理ゲー

例の同心円では、「フレームワーク（例：PrismやCommunityToolkit.MVVM）」は一番外側に位置づけられている。「詳細」 扱いされている。

つまり、ビジネスロジックやインターフェイスアダプターは、フレームワークやUIから完全に独立すべきだ、コンパイル時に依存すべきではない──という思想だ。

──が。

現代のソフトウェア開発環境を考えると、これは理想論に過ぎない場面が多い。

PrismのViewModelBase（BindableBase）に一切依存しないViewModel？
CommunityToolkit.MVVMのObservableObjectを完全に使わないデータバインディング？
WPFアプリで、DependencyPropertyやINotifyPropertyChangedに一切触れずにアプリを書く？

いや、現実には無理 でしょ。

現代の フレームワークは、もはや単なる「ソフトウェアレイヤー」ではない。
エコシステムそのものであり、前提であり、コンパイラをはじめとするビルドプロセスとも一体化している。言い方を変えると、ツールチェイン（Visual StudioやMSBuild）にも密接に組み込まれている

完全にフレームワークから独立した設計を目指すと、

コストが跳ね上がり
意味不明な抽象化地獄に陥り
開発スピードが死ぬ

ことになる。

※ Web界隈ならRailsのルーティングやActiveRecord、モバイル界隈ならAndroidやSwiftのフレームワークを、一切使わない設計を想像していただければと思います。

じゃあ、どうするか？

フレームワークの影響をゼロにするのは無理でも、影響をコントロールすることはできる。

具体的には：

ビジネスロジックのコアは、できるだけフレームワーク依存を局所化する（ゼロにできたら最高！）
- たとえば、DTO（データ転送オブジェクト）だけフレームワークの型を使い、ビジネスロジックはフレームワークに依存しないように設計する
インターフェース（境界線）を意識する
- たとえば、フレームワーク依存のAdapter層を用意して、UseCase層を守る
完璧を目指さない
- 「どこまで許容するか」をチームで合意して設計する

要するに、

「設計と現実」の間で、ちょうどいいバランスを取る

ということ。

それでも人は「クリーンアーキテクチャを実装した」と言いたがる

なぜか

──なぜなら、言いたいからだ。

「クリーンアーキテクチャで実装しています！」
とひとこと言えば、何かと安心されるし、かっこいい。

それがたとえ、同心円だけを真似た自己満足設計だったとしても。

クリーンアーキテクチャ、という言葉は、響きがいい。
同心円の図も、わかりやすそうに見える。
そしてなにより、マネージャー受けがいい。人事評価の実績としても。

くさい言葉でいえば、Uncle Bob が人生の大半を削って打ち立てた、クラフトマンシップの結晶(なはず) を、テンプレ情報商材扱いしていることに気がつかない。

逆に、そこまでわかって言ってたらすごいですけどねw

「達人（クラフトマン）」ならなんと言うか

本書の隅々まで目を通し、Uncle Bob の原理原則を理解した上で、自分（達）のアーキテクチャをクリーンに保っている人々は、きっとこういう風に言うんだろうと思う。「クリーンアーキテクチャ」を決してテンプレ扱いしたくないから。

クリーンアーキテクチャの原理原則に従ったアーキテクチャで実装しています。

もしくは、100歩譲って、こうだと思う。

クリーンなアーキテクチャで実装しています。

リトマス試験紙として・・・

つまり、実は「クリーンアーキテクチャ」という概念や言葉に対する接し方が、その人の技術者としてのレベルに対するリトマス試験紙みたいになっちゃってるんですかね？んー、怖((((；ﾟДﾟ))))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ

まとめ

「クリーンアーキテクチャ」という言葉を使うなら──

「クリーンアーキテクチャ」という言葉や同心円に、確立、テンプレ化された設計手法を期待してはいけない。
フレームワークとの現実的な距離感も考えなければいけない。
原理・原則を理解した上で、自分たちのプロジェクトに最適な「クリーン」を作り続けなければならない。

図を真似るだけではクリーンにならない。現実を知ったうえで、考え続けるしかない。「訳者あとがき」と丸被りだけど、それが、僕がこの本を読んで、そして現場でソフトウェアを作り続けて感じたこと。

おしまい