Clean Architecture/Robert C. Martin

アンクル・ボブの「Clean」シリーズ第3弾。「クリーン・アーキテクチャ」については、 ずいぶん前に記事が書かれていて、ググるとそれなりにたくさんの言及があります。

私はこれ、知らなかったです。というか、もしかしたら絵を見たことぐらいはあったのかもしれないですが、この絵を見てもここに何か自分の認識を改めるようなエッセンスがあるかどうかって全然わからないので、特に興味を惹かれなかったんだと思います。

で、この本の結論としては、この記事に出ているこの同心円の図がゴールよってことなんですが、そこに至るまでの道のりが丁寧にきっちり書いてあるので、なんかすごく楽しく、納得もしました。

そもそもこれが同心円になっている理由なんですが、恐らくは古典的なWebの3層モデルとか、MVCアーキテクチャみたいなものがあったとして、その両端、つまりGUIとDBがいずれも最も外側のレイヤーに来るよというようなイメージから来ているんだと思います。

GUIもDBもI/Oなんだから、それが一番下層であり、上から下への1次元のレイヤー構造で書き表すことももちろんできると思うんですが、わざわざ同心円にしているのはその対比のせいですよね。で、この一番外側GUIやDBが来るのはいいんですが、フレームワークも実装の詳細なんだから、一番外にいるべきだと。むしろ、そうさせないフレームワーク(本書の中では「結婚を迫る」というような言われ方をしますが)はよろしくないと。

それらがぜーんぶ一番外の層に来た上での、上の図のCtrlの中を3つのレイヤーにするぜという話で、じゃあ、そこにアプリケーションがどんなビジネスを体現するかに依らないソフトウエアアーキテクチャとしての3つのレイヤーがあるんですよと言われると、「ほう、それはちょっとすぐには思いつかないっすな」って感じじゃないですか。

で、一番内側はエンティティ。ぱっと考えるとエンティティってデータのことなんで一番内側もデータで、一番外側もデータ。どーすんのって思います。

もちろん、ボブおじさんのいうエンティティは、最も高次元のビジネスルールとそれを体現するデータ構造のことなので、RDBのスキーマ構造とは違うもの。つまり、Railsのようにアプリケーション設計において最も根源的なものとしてのビジネスルールとデータを実装の詳細に過ぎないRDBのスキーマを使って表現してしまうようなアーキテクチャを強いるフレームワークは一番よろしくないものってことになります。

よろしくないとどうなるかというと、変更と保守とデプロイが難しくなるよと。ボブおじさんのいうアーキテクチャの役割は、それらに寄与するため(だけ)なので、逆にRailsはそれと何をトレードオフしたのかって話です。ま、そう言われればそうかな。

というわけで、(本書でももちろん言及されているとおり)このアーキテクチャはコストが高いです。あの同心円ではさっぱりイメージがつかめないと思いますが、本書で示されている典型的なJavaで構築されたWeb+DBシステムの構造はこうなります。

かなーりリッチ。

<I>って書かれているのはInterfaceで、なんでこんなにやたら出てくるかと言えば、下位のレイヤーを上位のレイヤーは参照できないから。

例えば、DBアクセスで言えば「こんな構造のオブジェクトにデータ詰めてくれや」とユースケース層がData Access Interfaceを定義し、データアクセスをするコンポーネントがそれを実装して、DBから取ったデータを詰めて返すと。つまり、上位レイヤーをビルドするときに、下位のレイヤーをimportしないよと。そう出来て初めて、下位のレイヤーへの依存がなくなるわけです。

この方法を「依存関係逆転の原則」(DIP)と呼んでいて、この本を通じて、ひたすら何度も出てきます。要するに、DIPのDはDI(依存性注入)のDなわけです。SpringみたいなDIコンテナはお馴染みだし、仕組みも使い方も理解しているつもりですが、私はこのDIPという考え方を理解してはじめて存在意義と、ここでなんで"Dependency"という単語が使われているのか理解しました。はー、なるほどね。

で、とにかくモジュール(ソースファイルの単位ぐらいの意味)レベルでも、コンポーネントレベルでも、アーキテクチャを構成するレイヤーレベルでもDIP、DIP、DIPと何度も何度も出てきます。

そして、考えてみれば今こさえてるシステムでも全然できてないですわ。コントロールレイヤーとビジネスルールを形作るロジックのレイヤーとデータアクセスをするレイヤーとちゃんとレイヤー分割はしているけどDIPはまるっきり出来てないです。

しまいにはボブおじさんは「OOPの存在意義は、ポリモーフィズムを使ってDIPが簡単に実装できることだけだ」ぐらいのことを言い出します。でもまあ確かにコンポーネントを正しく分離するには依存関係がちゃんとしている必要があって、単なるユーティリティクラス以上のものをちゃんと交換可能にするためには、DIPされてないとダメだというのはまったくもってその通りです。

ただ、じゃあ本当にこの通りやるのか、こうならないフレームワークはだめなんかと言えば、それはケース・バイ・ケースってことになります。なんせこのアーキテクチャはコストが高いので。そこでバランスを取って何がベストか見極めるのがアーキテクトの仕事だし、そのベストはアプリケーションのライフステージによって変わるので、アーキテクトは常にコードを書きながら(このレベルで言うならば、コード書かないアーキテクトはあり得ない)、常に見極めていかなきゃならんわけです。

というわけで、ものすごく示唆に富み、なおかつ、読んでいて楽しい(ボブおじさんの昔話もいろいろ聞けるし)本です。そして、特にクラスを分割すべきかどうか、モジュールをどうまとめたら良いのかというレベルの設計方針に悩みを持っている人にお勧め。そのレベルの設計方針が積み上がって、最終的にはクリーン・アーキテクチャへたどり着くことになるからです。