はじめに
クリーンアーキテクチャって最近流行ってるけどよく分からない。理解しようとすると結構学習コストがかかりそうだし、必要になったタイミングで改めて勉強しよう...と思っている人いると思います（自分がそうでした）
そんな人向けに、この記事さえ読めばなんとなくクリーンアーキテクチャの本質が分かるようになる記事を書いてみました。
自分なりの解釈も混じっている部分もありますがご了承ください。
また、クリーンアーキテクチャを用いたディレクトリ構成もサンプルとして別記事に書いたので、もしご興味があればご覧ください。
【コード付き】クリーンアーキテクチャのディレクトリ構成例を丁寧に紹介 - Express
クリーンアーキテクチャとは
クリーンアーキテクチャとはビジネスロジック（ドメイン）を中心に置き、インターフェースの層や技術を外側に配置する設計アプローチです。
Robert C. Martin (Uncle Bob)氏が考案しました。
外部のフレームワーク（Expressなど）やデータベースといった「技術的な詳細」を最外層へ追いやり、一番大切なビジネスロジックを中心に配置します。
依存方向が肝となり、ビジネスロジックは技術的な詳細に依存してはいけません。技術の詳細がビジネスロジックに依存するようにします。
外側から中心という一方向に依存するようにコントロールすることで、変更に強くテストも容易な持続可能なソフトウェア開発が可能になります。
一言で言うと、こんな感じになるかと思います。
- 変更に強いソフトウェア設計法
- ドメイン（ビジネスロジック）が技術から独立したアーキテクチャ
- ビジネスロジック中心の設計法
- 層分けされた依存性逆転の設計法
じゃんけんアプリで例えてみる
正直今までの説明だと抽象的すぎてイメージしにくいかと思うので、具体例を出してみます。
例えばじゃんけんアプリで例えてみましょう。
じゃんけんでは「パーはグーに勝つ」というビジネスルールがあります。
このビジネスルールは、じゃんけんがじゃんけんとして成り立つ上でとても大切なルールです。
DBがMySQLからMongoDBに変わろうが、フレームワークがExpressからRailsに変わろうが、「パーはグーに勝つ」というルールは影響を受けてはいけません。
クリーンアーキテクチャは技術の詳細とビジネスロジックが疎結合のため、このような技術的な詳細の変更がビジネスロジックに影響を与えることなく変更することができます。
クリーンアーキテクチャが重要視していること
クリーンアーキテクチャは、特段新しい考えやアプローチではありません。
関係性の分離やSOLID原則を特に尊重した設計方針なのです。
個人的にはSOLID原則のうち以下の二つが特に強く現れていると思います。
- 依存性逆転（DIP）の原則
- ドメイン層（ビジネスルールなどが配置される）が技術的な詳細に依存しないようにする上でこの原則を使う
- 単一責任の原則
- 各層が一つだけの責任を持つためにこの原則を使う。Enterprise Business Rules層（ドメイン層）はビジネスルールを担当し、Frameworks & Drivers層（インフラ層）は技術の詳細を担当するなど
特に、依存性逆転の原則はクリーンアーキテクチャの本質でもあるので、あらかじめ理解しておいてください。
よくある誤解
以下の同心円は見たことありますか？
クリーンアーキテクチャについて調べると必ずと言っていいほど見かけますよね。
中心に向かっている矢印の向きが大事だ...というのは色々な記事で言及されていると思います。
しかしこの図をみる上で注意しなければならないことがあります。
それは、「必ず図通り、全部の層に分ける必要がある」という誤解です。
私も最初そのように思っていたのですが、実際にRobert C. Martin (Uncle Bob)氏の記事を見るとそうではないと言及されています。
Only Four Circles?
No, the circles are schematic. You may find that you need more than just these four. There’s no rule that says you must always have just these four.
DeepL日本語訳
4つの円だけ？
いいえ。この4つ以外にも必要なものがあるかもしれません。常にこの4つだけでなければならないというルールはありません。
つまり、この図の通り全部の層に分ける必要もなく、依存関係をしっかりコントロールすることが重要だということです。
この図があまりにも有名になりすぎてしまったため、誤解している人も多いのではないのかと思います。
まとめ
- クリーンアーキテクチャはビジネスルールを中心に置き、技術的な詳細は外側に追いやる設計
- ビジネスルールが技術的詳細に依存してはならない。技術的詳細がビジネスルールに依存しなければならない
- それを実現するために依存性逆転の原則（DIP）が関わってくる
- 同心円の図の通り層を再現する必要はない。依存関係を適切にコントロールすることが重要