「Clean Architecture　達人に学ぶソフトウェアの構造と設計」 を読んで気になったところを抜粋 その3

この記事は、岩手県立大学アドベントカレンダー12日目の記事です。

前回に引き続き、Clean Architecture についてとりとめの無い引用とコメントをします。

==

出、出〜頻繁見同心円図綺麗構造〜。

ソースコードの依存性は、内側（上位レベルの方針）だけに向かっていなければならない

円の内側は、外に依存してはいけないということだ。エンティティとは、ビジネスデータとビジネスロジックを扱うクラスとして考えよう。これはどのようなアプリケーションからも普遍的に利用出来る。

ユースケースは、アプリケーション固有のビジネスルールを取り扱う。

インタフェースアダプターは、その外にある存在を扱うのに便利なフォーマットに変換するアダプタである。

フレームワークとドライバは、DBやウェブフレームワークである。このレイヤはコードを書くことはあまりない。

この円をみたときには、なにを言っているのかさっぱりであった。しかしながら、実際にコードとしてみるとその利便性（と歯がゆさの両面）がわかる。

Clean Architecture はコード量が多くなる傾向にある。しかしながら、メンテ性能は高い。これはソフトウェアあるいはビジネスの寿命を加味しながら適切に活用する必要がある。僕が思うに、Clean Architecture は長い息のビジネスには大変に有用かと思う。一方で、ベンチャーのようにピボットと呼ばれることがあり得る世界にはオーバーエンジニアリングであると考える。

巷の記事にある Clean Architecture は、どうも熱心な信者が布教しているようで、この辺の案配を考慮せよと書いている記事は少ない。はじめは、もう少し層の薄いアーキテクチャを採用し、徐々に必要性に応じて Clean Architecture の層を増やす、というのが現実的な戦略ではないだろうか。

==

非常に頭のいい人たちが、抽象化が必要になることを予測してはいけないと提唱してきた。これがYAGNIの哲学である。このメッセージには、オーバーエンジニアリングのほうがアンダーエンジニアリングよりも悪質であるという知見が含まれている。だが、アーキテクチャの境界が必要なところになかったとしたら、境界を追加するコストやリスクは非常に高いものとなるだろう。

「YAGNI」という言葉は、エクストリームプログラミングから提唱された言葉である。必要になるまで機能を追加するな、あるいは早すぎる抽象化は悪、といったことが言われる。しかし、著者はここに疑問を呈している。ソフトウェアアーキテクトは未来に目を向けろという。完全に実装しろとはいわないが、実装すべきか無視するべきか常に見張り判断していけという。

近年でいう、XP、アジャイル、リーンといった手法は、未来は予測できないという前提にたつ。僕もその思想には一定の理解があるが、やはり人である以上、未来をある程度予測する必要があると考える。変化に機敏にというと言葉はいいが、場当たり対応は基本的には割けるべきことであり、リスクコントロールの範疇である。将棋やチェスの13手先は読めずとも、7手先くらいは読めたほうがいい。それには経験と知識が必要である。これこそ著者の言うことなのではないだろうか。

==

「訳者あとがき」はとてもおもしろい。僕がスッキリしないことをしっかりと書いている。

おそらく異論のある方もいらっしゃるだろう。私もすっきりしていない。例えばＷｅｂアプリケーションを開発するときに、フレームワークを選定しないことがあるだろうか？

訳者も納得していない様子だ。

だが、著者はこれまでの経験を引き合いに出しながら、圧倒的な説得力で力強く迫ってくる。おまえのアーキテクチャは、見ただけでわかるようになっているのか？ドメインについて正しく叫んでいるのか？そのように問いかけてくる。

そう。この本は、どうも疑問と思うところを圧倒的な言い切り方でねじ伏せてくる。それは、アンクルボブの経験と信頼が成せる技なのかもしれない。

フレームワークから着手しないことが本当に正しいことなのか、私にはまだよくわからない。本書で紹介されている例は、いずれも現代的なアプリの話ではない。正直、大昔の話を何度もされても困るのだが（翻訳も大変だし）、それでも「時代を超越した普遍のルール」が存在するとして、著者はいつまでも原理・原則に忠実であろうとする。

訳者の正直さがうかがえる。

本書で提唱されている「Clean Architecture」については、すでに著者本人がブログや講演などで情報発信していることもあり、見よう見まねでアーキテクチャの「同心円」を実装している例が数多く見られる。だが、著者のように原理・原則に忠実であるためにも、まずは本書に目を通してもらいたい。そして、著者と対話しながら、自らのアーキテクチャをクリーンに仕手もらえれば幸いだ。

多くのWeb記事はあまりにも稚拙だったと思う。このような背景を取り扱わず、単にあるプログラミング言語で同心円を実装しているに過ぎない。答えを求めすぎである。ある意味、アーキテクチャはアートであるから、すぐにそこにたどり着いてはいけない面もあるのではないだろうか。デザイン（設計）は、課題の解決案を示し、アートは、課題を問いかけるという。その面に立つと、アンクルボブが示した課題を単に受け入れるだけでなく、議論し、次に進めていく必要があるだろう。Clean Architecture は銀の弾丸ではない。

==

ここまで、全3回の感想を示した。

訳者ではないが、正直に言って僕も納得のいかない部分、あるいは理解しがたい部分がある。しかしながら、経験をまとめたベストプラクティスとしては秀逸なアーキテクチャなのだと思う。理解できない部分はエンジニア同士でぜひ議論をしていきたいです。興味のある方は、盛岡でランチでもしながらお会いしましょう。 連絡はこちら⇒ @isseium

技術系記事は書くのに時間がかかるので、明日以降そろそろポエムっぽい方向にいきたいと思っている次第です。