はじめに
『クリーンアーキテクチャ』という本があります。話題になっただけあり、いい本です。ぜひ読んでほしいと思うんですが、しかしまあ厚いし難しそうだし、ちょっと敷居が高いわけです。
https://www.amazon.co.jp/dp/B07FSBHS2V/ref=dp-kindle-redirect?_encoding=UTF8&btkr=1
でも思い返してみると、そんなに堅苦しい本じゃなかったような気がします。技術的な話もたくさん書いてありますが、それよりもそれ以外の話、磁気テープのころから続くソフトウェアの歴史の話とか、作者の体験談とか、そういうのがおもしろかったような。
この本もしかして、もっとてきとうに読んでいいんじゃないか？
そこで今回は、難しい部分は端折った雑な読み方を紹介してみたいと思います。
例の図
とても有名な図です。じっさい、技術的な部分はほとんど全部、この図に要約されているといっていいです。クリーンアーキテクチャを学ぶといったら、この図を実践することだといっていいでしょう。
この図が登場するのは第22章ですが、これより前の章はほとんど前提知識の解説だし、後の章は、図の説明と作者の所感です。つまり、技術的な話だけを求めるなら、ほとんどの部分は読み飛ばしていいです。
さて、この図を読むうえでもっとも大事なポイントは、
- ソースコードの依存関係は円の外側から内側に向かわなければならない
という点です。なにしろそう書いてあり、何度もはっきりと断言されています。クリーンアーキテクチャを実践するうえでは、なによりもこのことを重視しなければなりません。
いろんな用語の意味とか実装方法とかそういうのはともかく、この主張だけを理解すれば読んだ価値があったといえるでしょう。
その大前提を踏まえたうえで、この本の主張をもう少し理解するために重要と思うポイントは下の２点です。
- 依存関係逆転の法則(SOLID原則のD)
- データベースとフレームワークに依存するな
依存という言葉をよく使うので、いちおう少し説明します。
ＡがＢに依存するということは、ＡがＢのクラス、メソッド、変数などを参照するという意味です。クラス図ではだいたい、ＡからＢに矢印が引かれます。見慣れていないと間違えやすいところですが、この矢印は、データの流れを表すものではないので注意してください（データの流れと依存関係は逆になることが多いです）。
また、依存関係は循環してはいけないので、ＢがＡに依存することはありません。この場合、ＢはＡのクラス、メソッド、変数などを一切参照できないということになります。
依存関係逆転の法則
SOLID原則という言葉があります。堅牢で柔軟なソフトウェアを設計するために大切な５つの原則があって、それらの頭文字をつなげてSOLIDです。それぞれの意味についてはこの本にも解説されていますが、他の本やウェブにもたくさんの解説があるので、そちらを読むなら読み飛ばしていいです。
この５つのうち、最後のDが「依存関係逆転の原則」です。
少し説明します。
下の図のＡのような設計があるとき、これをＢに書き換えることができる。というのが、依存関係逆転の原則です。
なぜこんなことをするかというと、矢印の向きを反対向きにするためです。
図Ａでは、ServiceからRepositoryに向かって矢印が引かれています。このとき、これでは都合が悪いと設計者が考えるなら、図Bのようにインタフェースを使うことで矢印を反転させることができます。
ふつうにプログラムを書くと、図Ａのような設計になっちゃうと思います。しかし、作者であるボブおじさんはデータベースをレイヤーの外側に置くべきと考えており、矢印を逆向きにしなければなりません。だからこうしたテクニックを使う必要がでてきます。
最初の例の図の右下に、とってつけたようにクラス図みたいなものが書かれています。
この部分こそが、依存関係逆転の原則を説明したものです。図では例としてController、UseCase、Presenterの関係が描かれていますが、データベースに関してもまったく同じです。
技術的な話は他にもいろいろ紹介されているんですが、多くの話が、最終的にはこの一点につながっています。要するに矢印を揃えたいんです。
データベースとフレームワークに依存するな
最初の例の図で、データベースとフレームワークは一番外側に描かれています。依存関係は外側から内側に向かわなければならないので、つまりデータベースとフレームワークには依存するなということです。
円の外縁にはほかにもいろいろなものがあるんですが、読んでいて印象に残るのはこの２つです。個人的な感想ですが、この本が一番主張したいことはこれなんじゃないでしょうか。
なにかの理由で、データの参照先や保存先を変更しなければならないということは、じつはよく発生します。そうしたとき、深いレイヤーにあるソースコードがデータベースに依存している(SQLが書かれているなど)と、システム全体が影響を受け大変なことになります。
これを防ぐため、データベースに依存するコードを円の外側に追いやり、データベースに依存する部分をなくしておくことでリスクを避けるべきだ、というのがクリーンアーキテクチャの主張です。このために使うのが、依存関係逆転の法則などの道具です。
このデータベースの話、これにまつわる作者の体験談が、なんと３回も登場します。そのために本を書いたんじゃないかと感じるほどです。
フレームワークについても同じです。
フレームワークは便利ですが、多くの場合システム全体に依存を要求します。便利だから使っちゃうけど、しかし例えばフレームワークで対応できない事態が発生したとき、予想外のアップデートがきたとき、陳腐化し別のフレームワークを採用したくなったとき、フレームワークに依存したソースコードすべてに変更を加えなければならなくなります。このことはとても大きなリスクです。
この話。おそらく、多くのエンジニアにとって受け入れがたいものだと思います。
フレームワークに依存しないということは、フレームワークが提供する便利な基底クラスやユーティリティクラスを使えないということになります。たとえば便利なコレクションクラスとか、クールなクエリビルダとか、そういうものを、使うなということです。
じっさいのところ、いろいろな理由で難しい話だとは思うし、本にはそのことがほのめかされてもいます。
フレームワークに出会ったら、すぐに結婚しようとしてはいけない。その前に何らかの方法で時間稼ぎができないかを考えよう。
なんか苦労が偲ばれます。「時間稼ぎ」しかできなかったケースが、けっこうあったんじゃないでしょうか。
もちろん努力はするし、そのための方法も書かれているんですが、必ず厳密に適用できるものではないと考えてもよさそうです。
最後に
技術的にはいろいろな話が書かれていて、全部やってやろうと身構えると大変です。でも、全部やる必要はないんじゃないかと思います。
本にはソースコードがあまり出てきません。技術的な部分の説明もあまり詳しくありません。そういう本じゃないのかもしれないと思います。経験豊富なプログラマが、ソフトウェア設計についての歴史と体験を語る、エッセイみたいなものと考えちゃってもいいんじゃないでしょうか。
そして、そういう読み物として面白いです。たとえば第30章。もともと単純なファイルにデータを書き込む方針で開発していてそれで充分だったのに、「マーケティングの課題」のためにRDBMSを導入しなければならなくなった、という話が紹介されています。この話なんか最高です。
難しいところを端折ってしまえば、思いのほか気楽な本に見えてくるかもしれません。興味があればぜひ読んでみてください。