どうもTORAです。
今日ちょっと時間があったので、クリーンアーキテクチャを調べました。
Xでフォローしている有名なエンジニアの人たちのアカウントで、この言葉がやたら出てくるんですよ。前から気になってはいたんですが、ちゃんと調べたことがなかった。
で、だいたい分かりました。
業務ロジックそのものを円の内側に寄せて、外側の技術要素を円の外側に置く。フレームワークが何かとか、データベースが何かとか、将来変わりうるものですね。バージョンが上がって結構変わります、みたいなやつ。中心に置くのは純粋な業務ドメイン、エンティティです。そうすると、周辺の技術が進化したり変わったりしても、コアの業務仕様は影響を受けずにクリーンなまま保てる。
Javaで言うと、中心は本当にピュアなJavaです。フレームワークが一切介在しない、Java SEだけで書ける業務ロジック。外側とのやり取りはインターフェースで切る。
調べていて意外だったのは、これがぜんぜん新しい話じゃなかったことです。Uncle Bobが提唱したのが2012年。書籍が2017年。さらに遡ると、Hexagonal Architectureが2005年、Onion Architectureが2008年で、同じ依存性逆転の発想の延長にあるものらしいです。
14年前の概念なんですよ。
面白かったのはここから
じゃあなんで今これが話題になっているかというと、AI駆動開発と相性がいいらしいんですね。
「クリーンアーキテクチャで」と一言渡すだけで、AIはそれが何かを一発で理解する。当然、学習しているので。つまり、抽象度の高いやり取りが短い言葉でできる。
これ、僕が仕事でやっていることの逆方向なんですよ。
AIに渡す情報って、放っておくとどんどん増えます。Instructionsを書いて、禁止事項を足して、チェックリストを作って、手順を整備して。ルールが増えるほど品質は安定するので、そっちに寄せてきた。実際、うちのプロジェクトでもルールファイルが膨らみすぎてトークンを食うようになって、索引方式にスリム化したことがありました。
そこに対して、共通言語を1つ渡すだけでコンテキストが減る、という話です。
別にクリーンアーキテクチャじゃなくてもいい
たぶんこれ、クリーンアーキテクチャに限った話じゃないです。
「SOLIDの原則を守って」でもいいし、Repositoryパターンでも、Strategyパターンでもいい。粒度は全然違いますよ。クリーンアーキテクチャはアーキテクチャの話で、SOLIDは原則で、Repositoryはデザインパターンなので、並べる階層が違う。
ただ、名前が付いていて、その名前でだいたい同じものを指せる。少なくともシステム開発の文脈では、そこはブレない。
エンジニア同士の会話と一緒
これ、人間同士でも同じことをやってるんですよね。
基礎がしっかりしていて、スキルの高い人同士だと、事細かに説明しなくても話が通じます。「そこ、あのパターンで実装してるよね」「うんうん、そうそう」で終わる。それで確実に意思疎通が取れている。何十行も説明しなくていい。
AIとのやり取りでも、これができるという話なんだと思います。
今、みんなAIをコントロールしようとして、プロンプトに条件を細かく書いて、Instructionsファイルに書いて、agents.md に書いて、どんどん長くしていってる。何千行になることもある。僕も仕事ではそっちに寄せてきました。ルールが増えるほど品質は安定するので。
でも既存の概念や設計思想を知っていれば、大量の文章で伝えなくても、抽象度の高いやり取りで狙った結果が得られる。たぶんそっちが本質です。
設計パターンの名前は、それ自体が圧縮された仕様なんですよね。
で、人間同士との違いは、通じる相手の範囲だと思っていて。人間だと、共通言語が通じるのは同じ本を読んだ相手だけでした。AIは全部読んでいるので、名前を出せば必ず通じる。設計パターンの「意思疎通のコスト」を下げる部分だけが、急に効くようになったということかなと。
ただ、条件がひとつあって。
指示を出す側がその言葉に精通していないと使えないです。「クリーンアーキテクチャで」と言ってはみたけど自分が分かっていない、だと、出てきたものが正しいのか判断できない。結局そこは、AIが速くなっても変わらないところですね。
で、これ日本のエンタープライズでやってほしい
調べていて、AIの話より先にこっちを思いました。
僕がこれまで見てきたエンタープライズシステムって、業務ロジックとその時使っていた技術スタックが、もうぐちゃぐちゃに絡み合ってるんですよ。だから何かのバージョンを上げようとすると、業務仕様を壊すような変更をしてからリビルドする、みたいなことになる。それをずっと繰り返してきた世界です。
そこにクリーンアーキテクチャなんですよね。
技術要素から完全に隔離された、超ピュアな業務ロジックが中心にあって、依存の向きは技術要素から業務仕様への一方通行しかない。この設計で本当に作りきれたら、技術スタックのバージョンアップはもっと滑らかに進むはずです。
まあ、言うのは簡単なんですけど。「このアーキテクチャでやれば今までの苦労が楽になるんじゃないか」というチャレンジは、これまでも何度もあって、だいたい行うは難しなので。既存システムに後から入れるのは特にきついですし。
ただ今回は、動機がもう一つあるんですよね。バージョンアップが楽になるという昔からの理由に加えて、AIに伝わりやすいという理由が乗っかってる。同じ設計を、別の方向から2つが指してる。
これから新しく作るものなら選べます。個人で何か作るときも、その辺の言葉でAIとやり取りしてやってみようかなと思っています。
関連書籍
『Clean Architecture 達人に学ぶソフトウェアの構造と設計』をAmazonで見る
このリンクから購入すると、TORA BASEに紹介料が入ります。
