クリーンアーキテクチャの功罪
クリーンアーキテクチャというと設計における銀の弾丸のように扱われていて、クリーンアーキテクチャを導入するという記事をよく見ます。しかし自分の経験だとクリーンアーキテクチャで書かれているのにもかかわらず開発効率が落ちているという事が多く、いつでも使っておけばいいというものではないと思っています。
最近目にしたクリーンアーキテクチャに対する批判
本筋ではないので詳細は省きますが、あるとき[1][2]にUncle Bobの著書であるCleanシリーズへの批判をXで見ました。
ここで一番載せたかったものが今見つけられないのですが、以下のようなポストがありました。
書籍クリーンアーキテクチャに書いてある内容を抜きにして起こった現象だけを見るとマイナスの方が多い
このポストが自分の感じていることを端的に表現できているように感じました。書籍クリーンアーキテクチャの内容を悪いと思いませんが、その影響により起こっていることは悪いことのほうが多いというのは私の体験と一致します。
クリーンアーキテクチャで悪いことが起きる流れ
- 名前があまりにも良いのが卑怯でクリーンなアーキテクチャを否定する人など誰もいない
- いや特定の形をクリーンアーキテクチャと呼ぶのではなくクリーンなアーキテクチャについて述べた書籍だよというのはおそらく正しいが、例の同心円＝クリーンアーキテクチャという認識があまりにも普及している
- クリーンアーキテクチャという名前の書籍に「第22章 クリーンアーキテクチャ」があり、そこであの同心円が説明されているのでざっくり読むとそう思っても無理はないと思う
- 前述のポストのように（こういった余計な議論のない）良質な書籍は他にもあるのでそちらを読めばいいよというのもそのとおりだと思う
- 良すぎる命名と同心円のキャッチーさから不十分な事前知識のまま導入され、その後は手段と目的が逆転してしまいあの同心円をいかに正しく再現するかに腐心することになる
- これが内容を抜きにして起こった現象だけを見ると…というところ
特にWebフロントエンドにおいて思うこと
- 現在Webフロントエンドで良く使われるFWやライブラリにおいてクラスベースのやり方が変更検知やDIの面からマッチしない
- フレームワークを詳細だとして抽象化するのは単純なSPAならまだしもApp Routerのような複雑な仕組みの上でそれをやること自体が難しいのでは。とは言え現実的にフレームワーク置き換えだったり作り替えは数年スパンではあるので、そこで必要となるのはE2Eだったり少しずつ置き換えられるようになっているかとかではないか。逆にフレームワーク置き換えの際にFWを抽象化していたのでドメイン部分そのまま使えましたという話を聞いたことがない（あったら知りたい）
- 大体のWebアプリでは「ドメイン」と呼ばれるものはサーバーサイドで処理されていてフロントエンドはそのクライアントでしか無いと思う
- ここは扱うサービスの複雑さによる。サービスやフロントエンド自体が複雑だったり、フロントエンドが直接Firebaseなどを使ってデータの一貫性を保つ責任を持っていたりすると話は違うかも
- フロントエンドにおいてDOMやサーバー通信を抽象化することは現在あまりメリットがないと思う。HTMLを別のものに変更することやサーバーが置き換わることなどほぼ無いだろうし、テストの面でもDOMのままでもテストできるしサーバーはMSWでモックできるし、もっというとJestで直接の依存すらもモックできてしまう
- (ロジックを純粋関数やHooksに抜き出してテストしやすくするといったことを否定はしません)
結論
結局はクリーンアーキテクチャ≠あの同心円ということでしかないのですが、同心円をやるにしてもフロントエンドにおいては検討すべき点は多いのではと思います。
私が経験していないだけでクリーンアーキテクチャというかあの同心円をフロントエンドで適用して上手く行ってるよという話があればぜひ知りたいです。
追記
Clean Codeへの批判記事
某コメントで以下の記事を教えてもらいました。
書籍Clean Codeに載っているサンプルコードの問題についてが主な内容ですが、以下の記述になるほどと思いました。
Inexperienced programmers, meanwhile — (中略) — won't be able to distinguish the good advice from the bad, and won't be able to see that the example code is bad and shouldn't be imitated.
一方、経験の浅いプログラマーは、良いアドバイスと悪いアドバイスの区別がつかず、見本となるコードが悪いもので、真似すべきでないものだと見抜くことができない。
向き合うよりも距離を置くのも一つの手かも
本記事では結局クリーンアーキテクチャ≠あの同心円なので気をつけようという結論を書きました。しかし現実的にそれは抗いがたいものであるように感じます。私自身もこの記事を書いていて混同してしまって書き直すことが何度かありました。そもそもクリーンアーキテクチャも数ある書籍の一つでしかないわけで、そのような苦労を抱えて向き合うくらいならいっそ別の良質な書籍を読んで距離をおくのも一つの手ではないかと思います。
本記事の初めの方で掲載したポストではかわりに読むべき書籍としてソフトウェアアーキテクチャの基礎とマイクロサービスアーキテクチャを、前節で紹介した記事ではA Philosophy of Software Designを挙げています。私個人が他に候補をあげるならDomain Modeling Made Functionalや単体テストの考え方/使い方が思い浮かびますが他にも多くの候補があると思います。
-
https://www.itmedia.co.jp/news/articles/2312/14/news059.html ↩︎
-
このイベントにUncle Bobも登壇予定で、問題発覚後他の登壇者が出演を取りやめるなかで彼は逆の立場を取ったためにX上で批判が多かった ↩︎
Discussion