「Clean Architecture 達人に学ぶソフトウェアの構造と設計」を読んだのでそのまとめです。
はじめに
この本は、読んだ人によって賛否が分かれるでしょう。
それはなぜか。
「Clean Architecture」が何者であるかわからないまま、解説は進み、細かな説明がたくさん出てきた結果、最終的に何が言いたいのかよくわからなくなるからです。
「木を見て森を見ず」が容易に起こるし、さらには「例の図」に囚われてその答えを求めようとするとその答えは明記されていないので迷走します。
例の図*1
読む人にある程度予備知識がある場合、それらの知識をつなぎ合わせる良い地図に見えるかも知れません。
それでもなお、筆者が言いたいことを理解できるかどうかは相当に難易度が高く感じます。
先入観を捨てるために先に言っておきます。
先の図は、ヘキサゴナルアーキテクチャ、DCIアーキテクチャ、BCEのアーキテクチャを単一の実行可能なアイデアに統合したものだと説明されています。
図の右下にあるのは、円の境界をどう越えるかの例だと言っています。
この図については、34章あるうちの1つの章でしか扱われていません。
本全体で語られている内容の一部であり、もっと本質的に重要なことが含まれていません。
この図は大事なことを説明してはいますが、これに拘る必要はまったくありません。
本の構成
そこでまずは本の構成について解説します。
森を俯瞰するために、極力文章を減らすようにしました。
第I部 イントロダクション
アーキテクチャと設計には違いがないとし、
この本が優れたアーキテクチャと設計について説明してあるとなっています。
第II部 構成要素から始めよ
プログラミングパラダイムは何をすべきではないかを教えてくれたと言っています。
それらからアーキテクチャに活かせるエッセンスを学んでいます。
構造化プログラミングは、機能の分割を。
オブジェクト指向プログラミングはポリモーフィズムによって、コンポーネントの分離を。
関数型プログラミングは不変性によって、データ管理を。
第III部 設計の原則
SOLID原則は変更に強く、理解しやすい仕組みを与えるものです。
これにはコードレベルから始まりコンポーネントレベル、アーキテクチャレベルにも応用される内容が含まれています。
第IV部 コンポーネントの原則
コンポーネントはデプロイの単位です。
凝集性に関する3つの原則は、どうまとめるか、まとめないかの原則で、コンポーネントのサイズに影響する原則です。
- 再利用・リリース等価の原則（REP）
- 閉鎖性共通の原則（CCP）
- 全再利用の原則（CRP）
これは現在のチームに見合った落とし所を見つける必要があります。 それは簡単ではなく、さらに常に変わり続け、コンポーネントの構成も変わっていきます。
もう一種の原則は結合に関する3つの原則で、コンポーネントをどう結合させるかについてのエッセンスです。
- 非循環依存の原則（ADP）
- 安定依存の原則（SDP）
- 安定度・抽象度等価の原則（SAP）
第V部 アーキテクチャ
アーキテクチャの目的は、ライフサイクル（開発、デプロイ、運用、保守）を容易にすることです。
ソフトウェアシステムは「方針」と「詳細」に分割できます。
アーキテクトの目的は、方針とは無関係に詳細を決めながら、方針を最も重要な要素と認識する形状を作ることになります。
アーキテクチャとは、境界線を引くことであり、多くの章でどういったところに境界があるのかについて書かれています。
さらに境界線に関する考え方や変化する境界への対応、具体的な要素の境界についてもいくつか説明しています。
第VI部 詳細
外側の円に含まれる要素が詳細である理由を説明しています。
Clean Architecture とは
本には明記されていないので個人的解釈になります。 アーキテクチャがどういったものとして説明されているかを紹介しておきます。
アーキテクチャとは
アーキテクチャは、構築した人がシステムに与えた「形状」です。
アーキテクチャは、コンポーネントとそれらを分離する境界によって定義されます。
境界はあらゆるところに存在します。
どの境界を選び、完全に構築するのか、部分的にするのか選択できます。また、最適な落とし所は常に変わり続け、コンポーネントの構成も変わっていきます。
アーキテクチャの目的
アーキテクチャの目的は、システムのライフサイクルをサポートすることであり、開発、デプロイ、運用、保守を容易にすることです。
優れたアーキテクチャとは
ユースケースを中心にしており、周辺の関心事に依存しません。
アーキテクトとは
アーキテクトは、ソフトウェアをソフトに保つアーキテクチャを構築することを目的とします。
方針とは無関係に詳細を決めながら、方針を最も重要な要素と認識する形状を作り、詳細にとらわれず上位の方針を構築します。
アーキテクチャの境界をいつどこに作るのか、完全な境界なのか部分的な境界なのか、未来に目を向け現在のバランスを決めます。
Clean Architecture 指向
それでは、Clean Architecture とは何なのか。
Clean Architecture とは、言い換えると Clean Architecture 指向と言えそうです。
AgileやScrumは、エッセンスをなぞるだけではやっている（できている）とは言えず、自らがそこに飛び込み実践することで成り立ちます。
Clean Architectureも同様に、何かをなしたからClean Architectureであると言えるわけではなく、それに取り組み、未来に向けて実践していくことで成り立ちます。
本には次のようなことも書かれています。
システムはモノリシックとして生まれ、単一ファイルでデプロイされ、独立してデプロイ可能な単位になるまで成長し、最後はサービスやマイクロサービスまでたどり着くことが可能になるだろう。その後、物事が変わったときには、これまでの流れを逆転させ、モノリシックまで戻せるようになっておくべきである。
アーキテクチャは状況や時期に応じて変化するものであり、簡単に理解できたり、模範解答や雛形があるわけではありません。
それでも指針のようなものやエッセンスがあり、それらを学び、考え、状況に合わせて適応、対応していくことでClean Architectureを目指せるのだと思います。
あとがき
この連載は、重要だと思う内容をまとめたというよりも本を理解するために必要そうな内容をまとめたものになります。そのため、個人的解釈はなるべく含めないようにしています。
全体を俯瞰すると、アーキテクチャがいかに難しく一筋縄で解決できるものではないか、状況や時間に応じて変化するものであるか、どう対応していくべきか、について、またそれらを乗り越えるためにどういったエッセンスを使うのかを説明しているのだと理解できます。
コードレベルで立ち止まらず、アーキテクチャレベルに帰結することを認識すると、この本がまさにアーキテクチャについて語りたいのだと納得できます。
最後に、この本の良くないところは、その森がどういったものなのか、どういうルートで案内するのかを伝えないまま、ガイドが始まり、木の説明や木の歴史、ガイドの経験などをふんだんに交えて話が進む点にあります。
この概要の記事が、目の前の森（本）について、またこれから進む道筋について理解する助力になれば幸いです。
歴史的に解釈する
（追記 2020/4/22）
実は「SOLID原則」自体が、「Clean Architecture」の著者である Robert C. Martin、通称ボブおじさんが2000年に論文「Design Principles and Design Patterns」で発表したようです。
その後、Robert C. Martin が「Agile Software Development, Principles, Patterns, and Practices」を出版したのが2003年です。 邦訳版だと「アジャイルソフトウェア開発の奥義 : 原則・デザインパターン・プラクティス完全統合」で2004年です。
この中ではクラス設計の原則として「SOLID原則」、パッケージ設計の原則として凝集性と結合に関する6つの原則が出てきます。
「Clean Architecture」のエッセンスとして紹介されている内容はこの時点で既にあらかた揃っています。
「SOLID原則」から始まり、ボトムアップ的に解釈していく中で、システム全体のアーキテクチャという生き物に境界をどう引くか、という話が「Clean Architecture」です。
自身が提唱した原則の集大成として「Clean Architecture」という名を与えたわけです。
逆に言うと、原則をボトムアップ的に解釈していった結果できた指向、手法だから、それが何なのか、どういったものなのかと言われると、いちから説明しないと説明できない。
「Clean Architecture とは何なのか」、それが明記されていない理由はそこにあるんじゃないでしょうか。
更に言うと、Robert C. Martin は、「Clean Architecture」以外に「Clean」のつく本を、「Clean Code」、「Clean Coder」、「Clean Agile」の合計4冊出版しているようです。
「Clean Architecture」の「Clean」は彼の思想のようなものであり、「実体あるアーキテクチャ」ではない可能性が高いのではないでしょうか。
