Clean Architectureが全然わからなくなった

はじめに

Clean Architectureという概念に触れ数年が経ちました。完全に理解した -> 何もわからない -> 完全に理解した -> 何もわからない -> 全然わからない（今ここ）という変遷を繰り返し迷走する現在の自分の理解をなんとなく言語化してみます。

※今から記載する内容は筆者の2023年2月時点での現在の理解であり、実際に正しいものかどうかは保証できません。

Clean Architectureとは

Clean Architectureとは「変更が容易なソフトウェアを提供することを目指したソフトウェアの設計原則」です。
大事なことは原則であるという点です。

よく同心円の図でClean Architectureについて説明されますが、あれはClean Architectureの実装例であり、Clean Architectureそのものではありません。Clean Architecture自体は具体的なソフトウェアとしての形を持っておらず、あくまで原則を示すものです。

そして最も重要なものが

ソースコードの依存性は、上位レベルの方針にだけ向かっていなければならない

という原則です。

これは、重要ではない下位のルールに重要な上位のルールが依存してしまうと、変更が容易ではなくなってしまうため、上位レベルの方針にだけ依存性を向けることをルールとしています。

では、他にどんな原則があるのかという話になるんですが、正直上記以外の原則はないと思ってます。

上位レベルの方針とは

Clean Architectureの書籍を読むと、上位レベルの方針 = ビジネスルールとなっています。
確かに大体において、ビジネスルールを上位としてレイヤー分割を考えたほうが変更が容易になるアプリケーションが多いとは思います。しかし、必ずビジネスルールを最上位に置かなくてはならないのかと言われると、それは違うのでは？と思ったりしています。

なぜ違うのかと思ったのか、それは最近データ指向アプリケーションという言葉に出会ったことがきっかけです。そこでは「データの量、複雑さ、変化の速度」に対応するためのシステム設計がテーマになっており、データフォーマットやデータ量などが中心になっていました。

世の中にはデータをわかりやすく提供するということで価値を見出しているシステムがあります（例えば、SNSなど）。その場合はデータそのものが上位レベルの方針を言えるのではないか。そのようなデータが最上位になりうるシステムにおいて、ビジネスルールを上位レベルの方針とするのは間違っているかもしれない。つまりビジネスルールを必ず最上位と考えるのは間違いではないか、と思うようになりました。

データ指向からの考察は単なる一例ですが、少なくとも何を上位レベルの方針とするかはシステムによって色々変わりうるものだ、という理解をしています。

Clean Architectureのメリットについて

書籍を見ると、以下の5点がClean Architectureのプラスの特性（メリット）として記載されています。

• フレームワーク非依存
• テスト可能
• UI非依存
• データベース非依存
• 外部エージェント非依存

ただこれは、ビジネスルールを最上位レベルの方針としておいた場合のメリットであり、他の要素を最上位レベルの方針とした場合には、このメリットは別の内容に変わる可能性があります。

世の中で知られているこれらの特性も、Clean Architectureそのものではなく、具体例なんだな、という理解をしています。

結局Clean Architectureとは何か

色々迷走しているのですが、Clean Architectureに関する自分の理解は以下の2つです。

目的: 変更が容易なソフトウェアを作ること
原則: ソースコードの依存性を、上位レベルの方針にだけ向けること

逆に言えば、それ以外の要素は全て具体例であり、ビジネス要件によって変わり得るものだという認識です。

おわりに

この理解、抽象的すぎて、扱いにくいし、説明しにくいし、理解してもらいにくそうだし、どうしようかな〜という気持ちでいっぱいですが、とりあえず思ったままにアウトプットしてみました。

実際はClean Architectureってどういうものなんでしょうか、有識者の方、コメントお待ちしております。