nikkie-ftnextの日記

イベントレポートや読書メモを発信

読書ログ | Uncle Bobによるブログ記事「The Clean Architecture」（2012）感想

設計

はじめに

芦森詩音さん、お誕生日おめでとうございます！1
芦森だけに酒盛りじゃああああああ！！🍷（ルネッサ～ンス）2 nikkieです。

今回はクリーンアーキテクチャの原点、Uncle Bobによる「The Clean Architecture」（書籍ではなくブログ記事）の感想アウトプットです。

目次

「The Clean Architecture」（2012）

『Clean Architecture』（書籍）の元になった記事という理解です。
『ちょうぜつ本』や「Software Design 2023年6月号」をすでに読んでいて、「原典のブログに当たってみるか」と今回読んでみました。

Conclusionより

By separating the software into layers, and conforming to The Dependency Rule, you will create a system that is intrinsically testable, with all the benefits that implies.

この記事のポイントは2点と理解しました。

  • ソフトウェアを層に分ける（separating the software into layers）
  • ソフトウェアをThe Dependency Ruleに従わせる（conforming to The Dependency Rule）

層に分ける（＝レイヤ分け）

記事はシステムアーキテクチャの列挙から始まります。
オニオン・アーキテクチャなどなど

Though these architectures all vary somewhat in their details, they are very similar.

意訳 これらのアーキテクチャはみな詳細ではやや違うけれども、どれもとても似ている

似ている点は目的であり、それは関心の分離（separation of concerns）！
ソフトウェアを層に分けることで関心の分離を達成します。
なるほど〜、レイヤ分けは関心の分離のためだったのですね（たしかに、レイヤに分けること自体が目的ではないはず）。
一番小さい例としては、ビジネスルールに少なくとも1つの層、（外部との）インターフェースに少なくとももう1つの層と理解しました。

これらのアーキテクチャによりシステムは以下の5つの性質を持ちます：

  1. フレームワークからの独立
  2. テスト可能
  3. UIからの独立
  4. データベースからの独立
  5. 外部作用からの独立

要はビジネスルールを扱うシステムがメモリ上で動くようになっている（だからそれだけでテスト可能だし、独立も達成している）という理解です。

そしてカラフルな4つの同心円のあの図は、「an attempt at integrating all these architectures into a single actionable idea」（これらのアーキテクチャ全てを実用価値ある1つのアイデアに統合する試み）とのことです

つまり、（クリーンアーキテクチャの解説で語られていることですが、）Uncle Bobはシステム・アーキテクチャの観察を通じて1つの共通する抽象を抽出したということですね（4つの同心円の図）。
この共通性質はレイヤ分けだけで達成されるのではなく、レイヤ間の依存関係が肝と理解しました。

The Dependency Rule

ブログの中では斜体で強調されている語です。

This rule says that source code dependencies can only point inwards.

意訳: この規則は、ソースコードの依存は内側方向だけとするというものだ

4つの同心円のうち内側の円はどれも、外側の円にあるもののことを全く知りません。
つまり、外側の円で定義された関数、クラス、変数などを内側の円は知り得ないということです。

4つの層の説明

Entities、Use Cases、Interface Adapters、Frameworks and Driversの各層の説明です。
ちょうぜつ本1章を事前に読んでいたので分かりやすく感じました。

ここで説明される要素はすべて、4つの同心円のあの図に現れていたのですね。
黄色のEntitiesはEnterprise Business Rulesと説明されていますし、赤のUse CasesもApplication Business Ruleとなっています！

アプリケーションに関しては、成瀬さんの説明が非常にしっくりきているんですよ。

アプリケーションの目的は利用者の必要を満たしたり、目的を達成することです。（『ドメイン駆動設計入門』6章 Kindle の位置No.2088）

利用者の問題領域（ドメイン）に解法（システムとして実装）をapply（適用）するから、アプリケーションなんだ、と。
なので、Entitiesはアプリケーションがあろうがなかろうが存在するビジネスルールで、Use Casesはアプリケーションと関係するビジネスルールという理解です。

4つの円を説明した後で、どんでん返し！
「Software Design 2023年6月号」特集でも触れていました。

Only Four Circles?
No, the circles are schematic.

schematic＝概要を示した

クリーンアーキテクチャには同心円の数（4つ）が重要なのではなく、The Dependency Rule、レイヤが内向きにだけ依存するのが重要と理解しました。

  • 外側の円ほど
    • low level
    • 具体
    • 詳細
  • 内側の円ほど
    • high level
    • 抽象
    • policy（方針）

図の右下！ 境界の横切り方

flow of controlとsource code dependenciesの矛盾をどう解決するかも示されます。
鍵はDependency Inversion Principle！（依存性逆転の原則）

例えば、use caseがpresenterを呼び出す場合。

  • flow of controlは、use case -> presenter
  • でもsource code dependenciesは presenter -> use case だけにしたい！

The Dependency Ruleにより、use caseは外側の層にあるpresenterを知りません。
そこで、use caseは（同じ層にある）インターフェース Use Case Output Port を呼び出し、外側の円にあるpresenterは（内側のuse case層に依存できるので）Use Case Output Portを実装します。

use caseは同じ層にあるインターフェースだけを知っているのがミソですね！
実装では、use caseにはUse Case Output Portを受け取る引数があり、そこにpresenterインスタンスが渡って、実行されるのかな〜と考えています（手を動かしたい宿題事項）

この境界の横切り方の話、2020年のなるセミで出たところだ！！（31:20〜）

データの渡し方

境界を超えてデータをどう渡すかについても取り上げられます。

Typically the data that crosses the boundaries is simple data structures.

典型的には単純なデータ構造ということで、Data Transfer Objectをはじめいくつか列挙されます。

We don’t want to cheat and pass Entities or Database rows.

Entitiesやデータベースの行を境界を横切って渡しては、ブッブーですわ🙅‍♀️（> 過去の私）

終わりに

Uncle Bobによるブログ記事「The Clean Architecture」を読んでの感想や、現時点での理解を書き綴りました。
書籍で解説が充実してきたこともあり、ついに読破、完全理解の境地です🙌

重要なのは、内側のレイヤにだけ依存すること。
そして、依存性逆転の原則！（use case層に定義したインターフェースを実装したpresenterの例）

手を動かしたらすぐに何も分からなくなりそうなので、（「Software Design」誌の成瀬さんの章など）積極的に手を動かして乗り越えていきたいですね。

P.S. 6/9(金)からちょうぜつ本の読書pyはじまるよ！ 初回は1章「クリーンアーキテクチャ」

Python使い視点で技術書を読む、みんなのアウトプット中心の読書会のシーズン2はちょうぜつ本です！

シーズン1の常連さんもお久しぶりの方も、シーズン2からはじめましての方も、ちょうぜつ本やクリーンアーキテクチャに興味ある方、大歓迎です！
ぜひぜひお気軽にお越しください〜

個人的にはかわいい要素が楽しみすぎる〜

P.S. その2 GPT-4さん、「The Clean Architecture」を要約してくれちゃって、やべーな！

ちょうぜつソフトウェア設計入門――PHPで理解するオブジェクト指向の活用

ちょうぜつソフトウェア設計入門――PHPで理解するオブジェクト指向の活用

Amazon

Software Design (ソフトウェアデザイン) 2023年6月号 [雑誌]

Software Design (ソフトウェアデザイン) 2023年6月号 [雑誌]

Amazon

  1. 本日は素晴らしいお祝いがたくさん😭 ↩
  2. こちらぶりのこの言い回し ↩