🔖

Clean Architecture の『骨』

2023/03/27に公開

この記事のゴール

Clean Architecture とは何か。
あらゆる装飾を剥ぎ取ったそのエッセンスを一次テクストから読み解くことがこの記事のゴールだ。
一次テクストとは、 Robert C. Martin 氏のブログ記事 "The Clean Architecture" である。
同 Robert C. Martin 氏著の書籍『Clean Architecture』は参照しない。
Clean Architecture が初めて提唱されたのは、上記のブログであり、
いろいろな概念が付加される以前の「みずみずしいエッセンス」を抽出したいためである。

Robert C. Martin氏のブログ記事 "The Clean Architecture"

https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html

日本語訳:Robert C. Martin氏のブログ記事 "The Clean Architecture"

https://blog.tai2.net/the_clean_architecture.html

0. 【結論】Clean Architectureとは何か。

はじめに結論を記載する。
最後に改めて結論をまとめる。

Clean Architectureとは、主に「テスト容易性」や「変更容易性」を目的としたシステムアーキテクチャーである。
システムを抽象度ごとにレイヤーに分け、抽象度が低いレイヤーが抽象度が高いレイヤーに一方向に依存するようにする。
これにより、抽象度の高いレイヤーは抽象度の低いレイヤーの変更の影響が及ばなくなり、変更が容易になる。

筆者(私)がいいたいこと

Clean Architecture はオブジェクト指向プログラミングのみに限定される概念ではない

1. そもそもClean Architecture の目的は何か?

回答:

Clean Architecture の目的は

  • テスト容易性
  • 変更容易性

である。

原文

Conclusion

Conforming to these simple rules is not hard, and will save you a lot of headaches going forward. 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. When any of the external parts of the system become obsolete, like the database, or the web framework, you can replace those obsolete elements with a minimum of fuss.

(和訳)
結論

これらの簡単なルールに従うのは、難しいことではない。そして、頭痛がひどくなるのを防いでくれるだろう。ソフトウェアをレイヤーに分けることで、そして、依存性ルールに従うことで、本質的にテストしやすいシステムを作れるし、依存性ルールがもたらす恩恵ものきなみ受けられるだろう。システムの外部パーツ(データベースやウェブフレームワークなど)が古くなったら、それらの古臭い要素を、最小の取り組みで置き換えられる
(強調は引用者)

結論部分で述べられていること。

  • 本質的にテストしやすいシステムを作れる
  • システムの外部パーツ(データベースやウェブフレームワークなど)が古くなったら、それらの古臭い要素を、最小の取り組みで置き換えられる

これはつまり、

  • テスト容易性
  • 変更容易性

である。

2. Clean Architecture の目的(テスト容易性、変更容易性)を実現するにはどうすればよいか?

回答:

  • ソフトウェアをレイヤーに分ける
  • 依存性ルールに従うこと

ことで実現できる。
これも先に引用した結論部分に書いてある。

原文

"By separating the software into layers, and conforming to The Dependency Rule"(ソフトウェアをレイヤーに分けることで、そして、依存性ルールに従うことで)

という手段を用いることで前段で述べたテスト容易性、変更容易性が実現するとある。

3. 「ソフトウェアをレイヤーに分ける」とはどのような基準でレイヤーを分けるのか?

回答:

  • 抽象度別でレイヤーを分ける

原文

Only Four Circles?

Source code dependencies always point inwards. As you move inwards the level of abstraction increases. The outermost circle is low level concrete detail. As you move inwards the software grows more abstract, and encapsulates higher level policies. The inner most circle is the most general.

(和訳)
4つの円じゃないとダメなの?

ソースコードの依存性は、常に内側に向かう。内側に移るにつれて、抽象化のレベルは上がる。一番外側の円は、低レベルで具体的な詳細だ。内側に移るにつれて、ソフトウェアは抽象的になっていき、高レベルの方針をカプセル化する。一番内側の円は、もっとも一般性がある。
(強調は引用者)

原文を引用したようにソースコードがもつ抽象度別にレイヤーをわける。
「エンティティー」、「ユースケース」、「フレームワークとドライバー」などのレイヤーは抽象度で分けられているということだ。

4. 「依存性ルール」とは何か?

回答:

具体的で抽象度の低いレイヤーが抽象度の高いレイヤーに依存することである。
そして、その依存の方法性が一方向であることである。
つまり、抽象度の高いレイヤーが抽象度の低いレイヤーに依存してはいけない。
これによって、具体的で抽象度の低いレイヤーの変更は、抽象度の高いレイヤーに影響を与えないようにする。

原文

The Dependency Rule

The overriding rule that makes this architecture work is The Dependency Rule. This rule says that source code dependencies can only point inwards.

We don’t want anything in an outer circle to impact the inner circles.

(和訳)

依存ルール

このアーキテクチャを機能させる重要なルールが、依存ルールだ。このルールにおいては、ソースコードは、内側に向かってのみ依存することができる。

外側の円のどんなものも、内側の円に影響を与えるべきではないのだ。

この依存のルールこそが Clean Architecture の最も核に当たる部分であろう。

5. 結論 Clean Architecture とはなにか?(+ 筆者がいいたいこと)

回答:

Clean Architecture とは、主に「テスト容易性」や「変更容易性」を目的としたシステムアーキテクチャーである。
具体的には、

  • 抽象度別でレイヤーを分ける
  • そして抽象度別に分けたレイヤーは以下の依存のルールを守る
    • 具体的で抽象度の低いレイヤーが抽象度の高いレイヤーに依存する。
    • そして、その依存の方法性が一方向であることである。
    • つまり、抽象度の高いレイヤーが抽象度の低いレイヤーに依存してはいけない。
      • これによって、具体的で抽象度の低いレイヤーの変更は、抽象度の高いレイヤーに影響を与えないようになり、変更が容易になる。

という手法を用いる。
以上の手法によって「テスト容易性」や「変更容易性」というCleanさを目指しているものが、Clean Architecture である。

筆者がいいたいこと

Clean Architecture はオブジェクト指向プログラミングのみに限定される概念ではないということだ。
なぜなら、「結論」で述べたレイヤーや抽象度の依存のルールなどは、オブジェクト指向プログラミングに依存したものではないからだ。
オブジェクト指向の「依存関係逆転の原則(Dependency Inversion Principle)」などは、 これ自体が Clean Architecture というよりは、
Clean Architecture の依存のルールを実現するための手法としてみるほうが妥当ではなかろうかと私は考える。
したがって、関数型プログラミング、例えば Haskell や PureScript で大規模なアプリケーションを作るときでも、
Clean Architecture のレイヤーや依存のルールと言った方策は有効であろう。

6. この後はどうする。

ここまで論じてきたのが Clean Architecture の骨の骨に該当するものだと私は思う。
今後は、Robert C. Martin 氏著の書籍『Clean Architecture』などで具体的な「肉付け」を行っていけばよいと思う。

おまけChatGPT(無料版)の回答

chatgpt

同じ質問でもいつも同じ回答を返すとは限らないようだ。
ChatGPT も一方向の依存と言うのは理解している。
しかし、レイヤーの抽象度の概念がはっきりとは読み取れない。
(あくまで私が聞いたときは。)

●私
あなたはプログラマです。
Clean Architectureとはなにか簡潔に説明してください。

●ChatGPT

Clean Architecture(クリーンアーキテクチャ)は、ロバート・C・マーティン(通称:おじさん)が提唱するソフトウェア> のアーキテクチャの一つで、内側から外側へとレイヤー分けされた構成を取ることにより、コードの柔軟性、可読性、テスト容易性、保守性を高めるための設計原則です。

具体的には、ビジネスロジック、アプリケーション、インタフェース、フレームワーク/ドライバなどのレイヤーを定義し、各レイヤー間の依存関係が内側から外側に向かって一方向になるようにすることで、コードの変更に対する影響範囲を限定し、柔軟かつ保守性の高いアプリケーションを作りやすくすることを目的としています。

Discussion