「クリーンアーキテクチャ」が伝えてくれたことを平易な言葉で説明してみる

システム設計を論じる上で必ず出てくるクリーンアーキテクチャについて知った上で、良いシステムを作るために共通して大切にすべき考え方をまとめます。

クリーンアーキテクチャは、Robert C. Martinが提唱した概念で、
数々の歴史的な設計手法の考え方から、その根底にある良い設計についての考え方を抽出したものです。

The Clean Architecture - Clean Coder Blog

一口にコードと言っても、それぞれのコードが担当する処理は様々です。

例えば、Todoアプリを考えましょう。
データベースに入っているTodoタスクを条件によって抽出して、それを画面に表示するような機能が考えられます。

コードに実装すると、

①まずTodoタスクを検索する条件をユーザーの入力から受け取り、
②データベースに問い合わせるSQLを作成し、
③得られたデータを、画面を表示する際に扱いやすいような形に変換し、
④ユーザーに最終的な検索結果を画面表示する。

といった処理の流れがあります。

それぞれ、コードが担う役割は異なります。

• 検索する条件をユーザーの入力から受け取る
• データベースに問い合わせる
• 得られたデータを、扱いやすい形に変換する
• 最終的な結果を画面表示する

これらの処理がコードの中で無秩序に存在すると、そのコードが実際何をしているのか、どれだけの処理を行なっているのか、修正をするとどこに影響するのか、非常にわかりづいらものとなります。
長い目で見ると破綻することが予想されます。

ですので、役割によってコードを分類することが必要になってきます。

Todoアプリを実装するうえで重要な概念は、紛れもなくTodoタスクです。
Todoタスクは、「未対応」「対応中」「完了」といった状態を持ち、その状態を変えることができる必要があります。 また「カテゴリ」「タグ」などで分類することも必要でしょう。
そういったTodoアプリの根幹を表現するコードが必要です。

一方で、比較的サブ的な役割をするコードもあります。 データベースからタスク一覧のデータを取り出すことも、それをユーザーが見やすい形で画面上に表現することも、
アプリケーションを構成する上では当然必要です。

ビジネスロジック、データベース、画面表示といった役割をもったコードたちを分類（フォルダ分けや命名）をして、 互いになるべく密接に依存しないようにし、理解しやすいように整頓する必要があります。

• ビジネスロジック … Domain/*
• データベース … Repository/*
• 画面表示 … Presentation/*

クリーンアーキテクチャでは、この分類したそれぞれのコードの依存関係について言及します。

一言で言うなら、 「ビジネスロジックを中心に、他の全てのコードが依存する方向に実装すべき」 ということです。

ビジネスロジックは、そのアプリケーションが扱うビジネスの要件や手続きなどをコードで表現したものです。
クリーンアーキテクチャではエンティティと表現されています。

Todoアプリでいえば、Todoタスクがそれに相当するでしょう。
アプリケーションにおいて最も重要なのは、ビジネスロジックです。

そして、それをアプリケーションとして使えるものにするためには、ユーザーインターフェースやデータベースとの接続が必要です。 ビジネスロジックをアプリケーションとして成立させるための処理が必要です。つまり、これらはビジネスロジックに依存するということです。

逆に、ビジネスロジックが、データベースやユーザーインターフェースを前提に表現されることはありません。 つまり、ビジネスロジックは他のコードに依存しません。

これが「ビジネスロジックに対して他のコードは一方向に依存する」ということです。

ビジネスロジックは「目的」、データベースやユーザーインターフェースは「目的を叶えるための手段」 もいえそうです。

目的と手段が入れ替わってはいけません。
目的が変わらなければ、手段が変わることはありえます。

データベースにRDBの代わりにKVSを使うこともあるかもしれません。
ユーザーインターフェースがブラウザからCLIに変わるかもしれません。

しかし、ビジネスロジックという目的は変わりません。
手段は変えが効くようにするために、目的に対して依存するように実装するのです。

クリーンアーキテクチャの4層の円の図の「とおりに」作ることは、提唱者の真意から外れます。
クリーンアーキテクチャとは、具体的なコード規約を与えるものではなく、その考え方についての指針を与えるものです。

誰かが提唱した設計手法に忠実になるあまり、コードが無駄に膨大になってしまったり、
形式だけで意味のほとんどないコードが増えたりしてはよくありません。

システムによって解決したい顧客の課題に向き合うことが本質（ドメイン）にあり、 使っている言語やフレームワークの特性、工数と品質のトレードオフ、チームメンバーのスキルセットなどを考慮して どのような形で表現するのが適切なのかを考えるべきです。

クリーンアーキテクチャをはじめとした概念や設計手法は、あくまでその手助けをするものと位置付けるべきだと思います。