鵜呑みにしないで！ —— 書籍『クリーンアーキテクチャ』所感 ≪null 篇≫
はじめに
最近よくクリーンアーキテクチャが話題になってて、関心が高まってる感じしますよね！
ということでカブク社内でも書籍『クリーンアーキテクチャ』の輪読会が開催されました！
この記事は null 個人の考察です。
クリーンアーキテクチャとは
書籍を読んでみた結果、次のブログ記事がすべてだと言っていいと思いました。
- クリーンアーキテクチャ(The Clean Architecture翻訳) | blog.tai2.net
https://blog.tai2.net/the_clean_architecture.html
上記ブログ記事に比べて書籍に含まれる文字数は膨大ですが、膨大なのは前提知識（プログラミングパラダイムとか設計原則とか）と歴史と補足（と著者のカタルシス）です。
以下の私の記述は基本的に上記ブログ記事に対する考察と取っていただいても差し支えありません（ただし引用文は書籍からの拝借です）。
矛盾
「ビジネスルール」を「フレームワーク」「UI」「データベース」など（以下、書籍内の言葉を借りて「外部エージェント」と呼びます）に依存させたくない…
これはビジネスルールの保守性を重要視するソフトウェアの設計においてとても自然な欲求のように思います。
これを実現するためには、ビジネスルールと外部エージェントとの間に立ってデータの受け渡しや変換・実行制御を行うための中継役が必要になりますよね。クリーンアーキテクチャではこの中継役がインターフェイスアダプターという名前のレイヤーとして登場します。
インターフェイスアダプター
インターフェイスアダプターのレイヤーのソフトウェアは、ユースケースやエンティティに便利なフォーマットから、データベースやウェブなどの外部エージェントに便利なフォーマットにデータを変換するアダプターである。たとえば、GUIのMVCアーキテクチャを保持するのはこのレイヤーになる。プレゼンター、ビュー、コントローラーは、すべてこのインターフェイスアダプターのレイヤーに属している。モデルは、コントローラーからユースケースに渡され、ユースケースからプレゼンターとビューに戻されるデータ構造にすぎない。
同様に、このレイヤーでは、エンティティやユースケースに便利な形式から、永続フレームワーク（つまりデータベース）に便利な形式にデータを変換する。円の内側のコードは、データベースについて何も知らない。データベースがSQLデータベースであれば、すべてのSQLはこのレイヤー（特にデータベースに関係する部分）に限定する必要がある。
また、このレイヤーには、外部サービスなどの外部の形式から、ユースケースやエンティティが使用する内部の形式にデータを変換するアダプターも含まれる。
ビジネスルールと外部エージェントとの橋渡しを行う中継役は、ビジネスルール・外部エージェント双方を知っている必要があります。
クリーンアーキテクチャが革新的なのは、インターフェイスアダプターが外部エージェントに依存しないと謳っているところでしょう。
図22-1 クリーンアーキテクチャ
依存性のルール
図22-1 の同心円は、ソフトウェアのさまざまな領域を表している。一般的には、円の中央に近づくほどソフトウェアのレベルが上がっていく。円の外側は仕組み。内側は方針である。
このアーキテクチャを動作させる最も重要なルールは、依存性のルールである。
ソースコードの依存性は、内側（上位レベルの方針）だけに向かっていなければいけない。
円の内側は外側について何も知らない。特に、外側で宣言された名前は、内側にあるコードで触れてはいけない。これには、関数、クラス、変数、そのほかの名前付きソフトウェアエンティティが含まれる。
同様に、外側で宣言されたデータフォーマットは、内側から使ってはいけない。外側のフレームワークで生成されたフォーマットは特にそうだ。円の外側にあるものから内側にあるものに影響を及ぼしたくはない。
外部エージェントに依存することなく「ユースケースやエンティティに便利なフォーマットから、データベースやウェブなどの外部エージェントに便利なフォーマットにデータを変換する」ことは果たして可能でしょうか？
外部エージェントに便利なフォーマットへデータを変換しておきながら、 “あ、あんたなんかに依存してるわけないでしょ！ あんたのことなんか知らないんだからっ！” ってそれ…
インターフェイスアダプター（イメージ）
はっきり言ってしまいましょう。ツンデレです。じゃなくて、矛盾です。インターフェイスアダプターは外部エージェントについてよく知っている必要があり、この依存関係は逆転のしようがありません。したがって、 依存性のルールとインターフェイスアダプターの定義とが矛盾しています。
外部エージェントとインターフェイスアダプターとの依存関係を逆転できると勘違いする人がいるようです。インターフェイスアダプターには SQL さえも記述すると言っているのに、ですよ。もちろん、ものによっては、インターフェイスアダプターのレイヤーに抽象インターフェイスを用意して外部エージェント側で具象化することで、ソースコード上は依存関係が逆転しているように見せかけることもできるでしょう（一般に外部インターフェイスには「多くのコードは書かない」とのことですが、書こうと思えばの話です）。ですが、インターフェイスアダプターの役割的に、外側に何があるのか全く知らない状態では実装できません。これに対して、ユースケースはインターフェイスアダプターや外部エージェントについて全く知らない状態で実装できます（たとえば [Web フロントエンド] 状態更新ロジックをフレームワークから独立させる | Kabuku Developers Blog ではユースケースからフレームワーク（外部エージェント）を抽象化しており、実際に Angular と React とでユースケースのロジックを使いまわしています）。勘違いする方はこの違いがわからないのではないでしょうか。見かけの依存関係を逆転したところで、意味的な依存関係が逆転することは決してなく、それは単なる難読化でしかありません。
矛盾を解消するには、「インターフェイスアダプターの定義」「依存性のルール」のどちらかを変更しなければなりません。「インターフェイスアダプターの定義」を変更するとソフトウェアとして成立しなくなりそうなので、「依存性のルール」を変更する方が現実的でしょう。すなわち、 「ソースコードの依存性は、同じ方向とは限らない。」 というルールなら無矛盾になります。（しかしこれではノールールですね… よりまともなルールを考えてみてください。）
依存性のルールはクリーンアーキテクチャをクリーンアーキテクチャたらしめる核であり、依存性のルールを変更したアーキテクチャはもはやクリーンアーキテクチャではないと言えるでしょう。依存性のルールの変更が矛盾を解消するための現実解であることと合わせると、次の結論が導かれます。
クリーンアーキテクチャに則ったソフトウェアシステムは構築できません。
「クリーンアーキテクチャを勉強してみたけど 私にはむずかしくて実践できそうにない」と感じた方がいらっしゃるかもしれませんが、実際、誰がどうがんばっても実践できないので、安心して諦めていただきたいと思います。
クリーンアーキテクチャむずかしくて実践できないよ
クリーンアーキテクチャに則ってソフトウェアシステムを構築したと謳う記事を見かけますが、実際にソフトウェアとして機能しているとすればそれはクリーンアーキテクチャではなくオレオレクリーンアーキテクチャに則って構築されたのだと言えるでしょう。たとえば次のようなオレオレクリーンアーキテクチャが考えられます。
- インターフェイスアダプターが外部インターフェイスに依存している
- 本来「インターフェイスアダプター」であるはずの中継役を「外部インターフェイス」レイヤーに置くことで、中継役が外部インターフェイスとの境界をまたいでいないことにしている
このうち 1. は普通に使える普通のアーキテクチャだと思います。依存ルールがクリーンアーキテクチャと異なることに自覚的であれば尚良いのですが。一方 2. は書籍『クリーンアーキテクチャ』に「典型的なシナリオ」の例として登場する欺瞞です。とても腹立たしいです。存在するはずの境界を隠蔽することでレイヤーごとの関心事を不明瞭にする本末転倒なオレオレアーキテクチャだと言えるでしょう。
まとめ
ソフトウェアアーキテクチャ設計の目的はメンテナンスしやすいソフトウェアシステムの実現であって、クリーンアーキテクチャはその雛形の 1 案でしかないことに注意しましょう。名前付けられたアーキテクチャがソフトウェアエンジニアの共通語として普及することには大きな価値があるものの、クリーンアーキテクチャの実践そのものを目的としてしまっては手段と目的を取り違えていると言わざるを得ません。
クリーンアーキテクチャには矛盾が含まれており、クリーンアーキテクチャに則ったソフトウェアシステムは構築できないことを指摘しました。クリーンアーキテクチャの解説は曖昧な自然言語で書かれたものですから、矛盾しないような解釈もできるかもしれません。「ここは文字通り受け取ると矛盾するけど、こう解釈すれば意味が通るぞ！」といった忖度は意識的にも無意識的にも起こり得ます。ですが、個々人の忖度に委ねられる部分があればあるだけ、エンジニア同士の共通認識は構築できず、むしろ混乱の元となります。矛盾しているように見えるアーキテクチャを解釈でどうこうするより、もっと理解しやすく実践しやすいアーキテクチャを考える方が有益ではないでしょうか。（クリーンアーキテクチャの知名度を考えると強く言い切れないのが歯痒いところですが…）
おわりに
この記事が議論のきっかけになれば幸いです！
この記事を鵜呑みにせず、ぜひご自身で読んで理解してくださいね！
カブクではソフトウェアエンジニアを募集しています！
カジュアル面談ではカブクという会社についてご説明させていただきます！ オンライン面談も可！ 応募するしないは説明を聞いてから検討してみて！
その他の記事
Other Articles
2022/06/03
拡張子に Web アプリを関連付ける File Handling API の使い方
2022/03/22<selectmenu> タグできる子; <select> に代わるカスタマイズ可能なドロップダウンリスト
2022/03/02
Java 15 のテキストブロックを横目に C# 11 の生文字列リテラルを眺めて ECMAScript String dedent プロポーザルを想う
2021/10/13
Angularによる開発をできるだけ型安全にするためのKabukuでの取り組み
2021/09/30
さようなら、Node.js
2021/09/30
Union 型を含むオブジェクト型を代入するときに遭遇しうるTypeScript型チェックの制限について
2021/09/16
[ECMAScript] Pipe operator 論争まとめ – F# か Hack か両方か
2021/07/05
TypeScript v4.3 の機能を使って immutable ライブラリの型付けを頑張る
2021/06/25
Denoでwasmを動かすだけの話
2021/05/18
DOMMatrix: 2D / 3D 変形（アフィン変換）の行列を扱う DOM API
2021/03/29
GoのWASMがライブラリではなくアプリケーションであること
2021/03/26
Pythonプロジェクトの共通のひな形を作る
2021/03/25
インラインスタイルと Tailwind CSS と Tailwind CSS 入力補助ライブラリと Tailwind CSS in JS
2021/03/23
Serverless NEGを使ってApp Engineにカスタムドメインをワイルドカードマッピング
2021/01/07
esbuild の機能が足りないならプラグインを自作すればいいじゃない
2020/08/26
TypeScriptで関数の部分型を理解しよう
2020/06/16
[Web フロントエンド] esbuild が爆速すぎて webpack / Rollup にはもう戻れない
2020/03/19
[Web フロントエンド] Elm に心折れ Mint に癒しを求める
2020/02/28
さようなら、TypeScript enum
2020/02/14
受付のLooking Glassに加えたひと工夫
2020/01/28
カブクエンジニア開発合宿に行ってきました 2020冬
2020/01/30
Renovateで依存ライブラリをリノベーションしよう 〜 Bitbucket編 〜
2019/12/27
Cloud Tasks でも deferred ライブラリが使いたい
2019/12/25
*, ::before, ::after { flex: none; }
2019/12/21
Top-level awaitとDual Package Hazard
2019/12/20
Three.jsからWebGLまで行きて帰りし物語
2019/12/18
Three.jsに入門＋手を検出してAR.jsと組み合わせてみた
2019/12/04
WebXR AR Paint その２
2019/11/06
GraphQLの入門書を翻訳しました
2019/09/20
Kabuku Connect 即時見積機能のバックエンド開発
2019/08/14
Maker Faire Tokyo 2019でARゲームを出展しました
2019/07/25
夏休みだョ！WebAssembly Proposal全員集合！！
2019/07/03
W3C Workshop on Web Games参加レポート
2019/06/28
TypeScriptでObject.assign()に正しい型をつける
2019/06/25
カブクエンジニア開発合宿に行ってきました 2019夏
2019/06/21
Hola! KubeCon Europe 2019の参加レポート
2019/06/19
Clean Resume きれいな環境できれいな履歴書を作成する
2019/05/20
[Web フロントエンド] 状態更新ロジックをフレームワークから独立させる
2019/04/16
C++のenable_shared_from_thisを使う
2019/04/12
OpenAPI 3 ファーストな Web アプリケーション開発（Python で API 編）
2019/04/08
WebGLでレイマーチングを使ったCSGを実現する
2019/03/29
その1 Jetson TX2でk3s(枯山水)を動かしてみた
2019/04/02
『エンジニア採用最前線』に感化されて2週間でエンジニア主導の求人票更新フローを構築した話
2019/03/27
任意のブラウザ上でJestで書いたテストを実行する
2019/02/08
TypeScript で “radian” と “degree” を間違えないようにする
2019/02/05
Python3でGoogle Cloud ML Engineをローカルで動作する方法
2019/01/18
SIGGRAPH Asia 2018 参加レポート
2019/01/08
お正月だョ！ECMAScript Proposal全員集合！！
2019/01/08
カブクエンジニア開発合宿に行ってきました 2018秋
2018/12/25
OpenAPI 3 ファーストな Web アプリケーション開発（環境編）
2018/12/23
いまMLKitカスタムモデル（TF Lite）は使えるのか
2018/12/21
[IoT] Docker on JetsonでMQTTを使ってCloud IoT Coreと通信する
2018/12/11
TypeScriptで実現する型安全な多言語対応（Angularを例に）
2018/12/05
GASでCompute Engineの時間に応じた自動停止/起動ツールを作成する 〜GASで簡単に好きなGoogle APIを叩く方法〜
2018/12/02
single quotes な Black を vendoring して packaging
2018/11/14
3次元データに2次元データの深層学習の技術(Inception V3, ResNet)を適用
2018/11/04
Node Knockout 2018 に参戦しました
2018/10/24
SIGGRAPH 2018参加レポート-後編（VR/AR）
2018/10/11
Angular 4アプリケーションをAngular 6に移行する
2018/10/05
SIGGRAPH 2018参加レポート-特別編（VR@50）
2018/10/03
Three.jsでVRしたい
2018/10/02
SIGGRAPH 2018参加レポート-前編
2018/09/27
ズーム可能なSVGを実装する方法の解説
2018/09/25
Kerasを用いた複数入力モデル精度向上のためのTips
2018/09/21
競技プログラミングの勉強会を開催している話
2018/09/19
Ladder Netwoksによる半教師あり学習
2018/08/10
「Maker Faire Tokyo 2018」に出展しました
2018/08/02
Kerasを用いた複数時系列データを1つの深層学習モデルで学習させる方法
2018/07/26
Apollo GraphQLでWebサービスを開発してわかったこと
2018/07/19
【深層学習】時系列データに対する１次元畳み込み層の出力を可視化
2018/07/11
きたない requirements.txt から Pipenv への移行
2018/06/26
CSS Houdiniを味見する
2018/06/25
不確実性を考慮した時系列データ予測
2018/06/20
Google Colaboratory を自分のマシンで走らせる
2018/06/18
Go言語でWebAssembly
2018/06/15
カブクエンジニア開発合宿に行ってきました 2018春
2018/06/08
2018 年の tree shaking
2018/06/07
隠れマルコフモデル 入門
2018/05/30
DASKによる探索的データ分析(EDA)
2018/05/10
TensorFlowをソースからビルドする方法とその効果
2018/04/23
EGLとOpenGLを使用するコードのビルド方法〜libGLからlibOpenGLへ
2018/04/23
技術書典4にサークル参加してきました
2018/04/13
Python で Cura をバッチ実行するためには
2018/04/04
ARCoreで3Dプリント風エフェクトを実現する〜呪文による積層造形映像制作の舞台裏〜
2018/04/02
深層学習を用いた時系列データにおける異常検知
2018/04/01
音声ユーザーインターフェースを用いた新方式積層造形装置の提案
2018/03/31
Container builderでコンテナイメージをBuildしてSlackで結果を受け取る開発スタイルが捗る
2018/03/23
ngUpgrade を使って AngularJS から Angular に移行
2018/03/14
Three.jsのパフォーマンスTips
2018/02/14
C++17の新機能を試す〜その1「3次元版hypot」
2018/01/17
時系列データにおける異常検知
2018/01/11
異常検知の基礎
2018/01/09
three.ar.jsを使ったスマホAR入門
2017/12/17
Python OpenAPIライブラリ bravado-core の発展的な使い方
2017/12/15
WebAssembly（wat）を手書きする
2017/12/14
AngularJS を Angular に移行: ng-annotate 相当の機能を TypeScrpt ファイルに適用
2017/12/08
Android Thingsで4足ロボットを作る ~ Android ThingsとPCA9685でサーボ制御)
2017/12/06
Raspberry PIとDialogflow & Google Cloud Platformを利用した、3Dプリンターボット(仮)の開発 (概要編)
2017/11/20
カブクエンジニア開発合宿に行ってきました 2017秋
2017/10/19
Android Thingsを使って3Dプリント戦車を作ろう ① ハードウェア準備編
2017/10/13
第2回 魁！！ GPUクラスタ on GKE ~PodからGPUを使う編~
2017/10/05
第1回 魁！！ GPUクラスタ on GKE ~GPUクラスタ構築編~
2017/09/13
「Maker Faire Tokyo 2017」に出展しました。
2017/09/11
PyConJP2017に参加しました
2017/09/08
bravado-coreによるOpenAPIを利用したPythonアプリケーション開発
2017/08/23
OpenAPIのご紹介
2017/08/18
EuroPython2017で2名登壇しました。
2017/07/26
3DプリンターでLチカ
2017/07/03
Three.js r86で何が変わったのか
2017/06/21
3次元データへの深層学習の適用
2017/06/01
カブクエンジニア開発合宿に行ってきました 2017春
2017/05/08
Three.js r85で何が変わったのか
2017/04/10
GCPのGPUインスタンスでレンダリングを高速化
2017/02/07
Three.js r84で何が変わったのか
2017/01/27
Google App EngineのFlexible EnvironmentにTmpfsを導入する
2016/12/21
Three.js r83で何が変わったのか
2016/12/02
Three.jsでのクリッピング平面の利用
2016/11/08
Three.js r82で何が変わったのか
2016/12/17
SIGGRAPH 2016 レポート
2016/11/02
カブクエンジニア開発合宿に行ってきました 2016秋
2016/10/28
PyConJP2016 行きました
2016/10/17
EuroPython2016で登壇しました
2016/10/13
Angular 2.0.0ファイナルへのアップグレード
2016/10/04
Three.js r81で何が変わったのか
2016/09/14
カブクのエンジニアインターンシッププログラムについての詩
2016/09/05
カブクのエンジニアインターンとして3ヶ月でやった事 〜高橋知成の場合〜
2016/08/30
Three.js r80で何が変わったのか
2016/07/15
Three.js r79で何が変わったのか
2016/06/02
Vulkanを試してみた
2016/05/20
MakerGoの作り方
2016/05/08
TensorFlow on DockerでGPUを使えるようにする方法
2016/04/27
Blenderの3DデータをMinecraftに送りこむ
2016/04/20
Tensorflowを使ったDeep LearningにおけるGPU性能調査
関連職種
Recruit