書籍『Clean Architecture』のエッセンスは、2つのルールだけ
2018年7月、書籍『Clean Architecture』の日本語版が発売されました。全34章にわたり、クリーンな、つまり開発・保守コストの低い、ソフトウェアアーキテクチャを導くルールが詳述されています。
この記事では、同書の提唱する特に重要な2つのルールをご紹介します。いや、特に重要どころか、これら2つのルールを全34章に展開したものが同書だとすら思っています。言い過ぎでしょうか。ともかく、未読の方にはよい道案内になるはずです。
2つのルール
さっそく、その2つのルールを見てみましょう。
- アクターの異なるコードは分割するべき（第7章）
- ソースコードの依存性は、内側だけに向かっていなければいけない（第22章）
以下、これらのルールについて、ぼくの理解をまとめてみます。
ルール1：アクターの異なるコードは分割するべき
「アクター」とは
同書では、システムの「変更を望む人たちをひとまとめにしたグループ」のことを「アクター」と定義しています。ユースケースのアクターのことだと思ってよいでしょう。
弊社ベルトラでいえば、「管理者がアクティビティを登録する」「旅行者がアクティビティを予約する」を始めとして、さまざまなユースケースがあります。この場合「管理者」や「旅行者」がアクターです。
なぜ分割するべきなのか
アクターごとにコードを分割しなかった結果の失敗例が、同書には2つ挙げられています。
- 想定外の重複（例：管理者向けに編集したコードが実は旅行者向けにも使われていてデグレを起こす）
- マージ（例：管理者向けに編集したコードが旅行者向けに編集したコードとコンフリクトする）
このような失敗を避けるため、アクターのコードは分割するべきというわけです。
ルール2：ソースコードの依存性は、内側だけに向かっていなければいけない
「依存性」とは
2つ目のルールに登場する「依存性」は、DI（Dependency injection、依存性の注入）パターンの「Dependency」のことです。
たとえば、AというクラスがBというクラスを参照しているとき、AはBに依存しています。この関係を「AにはBへの依存性がある」と表現できます。
「内側」とは
同じく2つ目のルールに登場する「内側」については、同書のもととなったブログ記事「The Clean Architecture」（日本語訳）冒頭の図を見ていただくとわかりやすいでしょう。
いちばん外側にはデバイス、ウェブ、DB、外部インターフェイス、UIが置かれています。システムの入出力にもっとも近い要素です。
いちばん内側には置かれているのは、企業のビジネスルールです。UIのデザインが変わろうが、DBのスキーマが変わろうが、ビジネスルールは変わわりません。つまり、システムの入出力からもっとも遠い要素というわけです。
なぜ内側だけに向かっていなければいけないのか
ここで仮に、ユースケースを実装したクラス（内側から2番目）がDBクラス（いちばん外側）を直接参照しているとしましょう。その結果、どうなるでしょうか。
たとえば、DBのスキーマを変えたり、RDBからKVSに移行したりする際に、ユースケースクラスのコードを書き換えなければならなくなるかもしれません。そのような設計は、保守コストの低い（クリーンな）アーキテクチャとはよべないでしょう。外側の変更が内側に影響してしまっています。
保守コストを下げるには、ユースケースクラスに、DBクラスではなくインターフェイスを参照させます。参照するのがインターフェイスならば、そのインターフェイスを実装したオブジェクトの「注入」が可能になるからです。
ユースケースクラスの開発を進めたいとき、DBの準備が整っていなかったとしても、モックオブジェクトを注入すれば進められますよね。これも、内側への依存性だけを許可するメリットのひとつです。
まとめ
以上、書籍『Clean Architecture』のエッセンスをご紹介しました。
ぼくはすっかり感化されてしまい、ルールをできるだけ守って、保守コストの低いシステムを実現していきたいとメラメラしている次第です。
同じくメラメラしたい方には一読をおすすめします。ルールの載っている第7章と第22章、そしてルールの適用事例が書かれている第33章だけで、元が取れると思います。
