ネオガチクリーンへの道①：クリーン警察の一日

## クリーン警察、それは…

今日もどこかのリポジトリに、密かに埋め込まれる謎の依存関係。

そこに現れる――**クリーン警察**。

この記事では、そんな “Clean Architectureガチ勢” の日常を通じて、

- 「どこが危ないの？」
- 「そもそも Clean Architecture って何を守ればいいの？」
- 「その設計、ガチ？ヌル？」

を **やさしく（でもガチで）** 解説していきます。（いくかもしれません 笑）

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4041503/fc6506ee-f493-4dc4-b1f0-9e548b4c8d05.png)

:::note
この物語はフィクションです。
:::

## ある日のパトロール

都内、青物クロスリンク駅にほど近い庁舎の一室。警視庁サイバー局に設けられたクリーン対策課では日課のサイバーパトロールが行われていた。主任である同心警部補は昨晩の五反田ミッドタウンでの「パトロール」の後遺症である頭痛と眠気で仕事にならない。



「同心主任！やばいっす！Clean Architecture Sample って書いてあるのに、プロジェクトがひとつしかない構成、JitHubで発見しました！しかも `Entities.cs`, `UseCases.cs`, `Presentation.cs` がそれぞれ1ファイルです！」

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4041503/8dfbf076-ef44-45c9-9c18-fd012decf566.png)

「ほぉ……」

「しかもこれ、IRepositoryが何たらとかそれっぽく書いてあって、しかもQiikaに解説記事まで書いてあります！初心者殺しの臭いがプンプン、いやむしろ故意犯といってもいい状況です！」

「……ふむ。“クリーンアーキテクチャ”と名乗ってはいるが、中身は……1箱詰め合わせ。依存がどこに向いてるかなんて、作った本人すら分からない――そういうのがね、“**ヌルクリーン**”なんです。ええ。」

（円三郎、ゆっくりと椅子を回す）

「……あのですね、たとえばですよ。たとえばあなたが、クリーンアーキテクチャだと称して構成を公開する。そして一つのプロジェクト ―― コンポーネントと言ってもいい ―― に、`Entities.cs`、`UseCases.cs`、`Presentation.cs` が一枚板のように同居していたとしましょう。構造は、まるで鍋の中の具材。分かれているようで、全部いっしょくた。うまいかまずいかはさておき――少なくとも、それは**分かれていない**。」

「でね、ここからが肝心なんですが……“分かれていない”ということは、“依存の向き”も自由ということなんです。誰が誰に依存しているのか、どこからどこまでが内側なのか、それがもう、**ぜんっぜん分からない。** ファイル同士の相互依存 ――**循環参照・密結合**―― もあり得る世界。」

「つまり、何があっても**コンパイル時に止まらない依存構成**というわけです。」

「Dependency Injection のサンプル、ですか……ええ、それらしき名前のファイル名で、  “注入する側もされる側も、全部ひとつの箱に入ってる”――そんなコード、見たことありませんか？  それはもう、“分けてない”というより、“混ぜただけ”。ええ、**設計とは呼べません。**」

この時、円三郎はすでに確信していた。**プロジェクトが1つしかない時点で、この「自称クリーンアーキテクチャ」は既に“壊れて”** いたのだ。

「ちなみに、『みつけつごう』の『みつ』は『はちみつ』の『蜜』じゃありませんよ。『ひみつ』の『密』。ええ、“コードはいくら書き散らしても、甘くはならない”――ね、さらっと書くのが美しいんです。」

立ち上がりながら、帽子をかぶる。

「……行きましょう。これは、どうやら“故意の再犯”かもしれません。」

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4041503/3f31f757-e190-4786-830b-0f7f82d6eb75.png)

## 今日の教訓

クリーンアーキテクチャを志向するのであれば、まず、**コンポーネントを切る**ことから始めましょう。

「コンポーネント」とは、ビルド単位あるいは明示的な依存制御ができる単位のこと。C# ではプロジェクト（アセンブリ）、Java では jar や module、Python や JavaScript では import 可能なパッケージやディレクトリが該当します。

つまり、「依存の向きをコード上で明確に制御できる単位」こそが、Clean Architecture における **境界線（Boundary）** になります。

見た目上はレイヤ分離されているように見えても、実際には Presentation 層が UseCase に定義された型を参照し、さらには UseCase 側でも Presentation 側の具象型（例：WPFのDialog）に依存している……といった **循環依存** のような構成は意外とよくあります。コンポーネントを分けないと、循環依存すら発生してしまう可能性があるのです。これが、**ヌルクリーンと呼ばれる（私が勝手にそう呼ぶ）状態**です。

そこで、「**クリーンアーキテクチャの原理原則に従う**」ためには、「**コンポーネントを切る**」ことが第一歩となります。**依存関係を設計するためには、そもそも“依存元・依存先を明確に分ける必要がある”** からです。

```
NG: Presentation ←→ UseCases ←→ Entities（依存が双方向）
OK: Presentation → UseCases → Entities（一方向）
```
このNG例の「矢印の向き」がコンパイルエラーで止まる構成になっていれば、あなたのソリューションはもう、ヌルクリーン卒業、準クリーン道場の門前に立っています。

## 今日のまとめ：クリーンの第一歩は「矢印の向きを強制できる構成」にあり
* ファイル分けやフォルダ分け ≠ コンポーネント分離
    * ファイルやフォルダを分けただけではコンポーネント分割では**ない**
* インポート（参照）制御ができて初めて「分かれている」と言える
* クリーンアーキテクチャの原理原則は、まずコンポーネント単位（ビルド単位）で線を引くこと

そしてその先に、「依存関係の制御」が登場するのです。


:::note
ポイント
クリーンアーキテクチャへの第一歩は
**【徹底的なコンパイル時依存関係への意識】**
:::

## (非公式)用語解説

|種類|ざっくり|例|
|---|---|---|
|ヌルクリーン|名前だけ|コンポーネント切っていない、循環参照、etc…|
|準クリーン|軽微な反則|TBA|
|ガチクリーン|ガチ勢|TBA|
|ネオクリーン|発展的解釈|TBA|
|ネオガチクリーン|ガチかつ発展的|TBA|

## 待て、次回・・・

次回（予定）：「#ネオガチクリーンへの道②：一方通行違反」
→ コンポーネント間の一方通行違反を探るテクニックに迫るかも？