SOLID の設計原則という言葉はたびたび耳や目にしており、なんとなく守ると良さそう、でも実際に実装するとなると悩むところが多々あるという状態でした。
業務でレビューをする中でも、SOLID の設計原則に違反しているのでは？と思うところで、うまく説明できないこともあり、SOLID に対する学習欲が高まっていたところでもありました。
そんな中、ドライブによるお出かけのお供と化している「リファクタリングとともに生きるラジオ: リファラジ」を聞いていると単一責任の原則（SRP）について、Clean Architecture を参照しながらお話している回がありました。
「Clean Architecture、そういえば積読の下の方に眠っているな…」ということで、長き眠りから呼び起こし、年末年始のお休みで読んでみた次第です。
（実際は1月下旬ころまでかかりました…）
- クリーンアーキテクチャとは？
- 設計原則の内容、生まれた背景は？
- 優れたアーキテクチャを選択するための思考法
「Clean Architecture」から、これらの知識を得ることができました。
勘違いしている部分もあるかもしれませんが、現時点での理解をまとめておきたいと思います。
この記事では、「Clean Architecture」を読んで得た設計原則・クリーンアーキテクチャの個人的な見解をお伝えします。
SOLID 原則の理解促進とコンポーネントの原則の認知
SOLID 原則がどういう背景をもとに生まれたもので、それを踏まえてどう実装すればいいのか。
非常にぼんやりとした輪郭だったものが徐々にはっきりしてきた感覚があります。
1つのクラスや1つのメソッドがそれぞれ単一の責務を全うするという理解でいました。
ただ、それが「何に対しての責務なのか」という点を意識できていないことにより、誤った分割をしていたと気付きました。
RDRAなどでアクターを明確にすることで、単一責任の原則もより責務を明確にしたものにできそうな気がしています。
拡張に対して開いていて、修正に対して閉じていなければならない。
この文言だけ聞くと、拡張と修正は何が違うのか？という疑問にぶつかっていました。
「Clean Architecture」を通して、これまで依存関係逆転の原則のために用意したインターフェースがオープン・クローズドの原則も満たしていることを理解しました。
さらに、分割の視点として機能ごとと階層構造化という2通りの視点があるということも、ここで学びました。
正直これは「Clean Architecture」を読むことで理解が進んだかというと、そうではない部類に入ります。
結果として、リスコフの置換原則を知りたい意欲に駆られ、「SOLID原則完全に理解した！になるための本」に記載されていた以下の説明で腹落ちしました。
一般に、継承はis-aの関係と言われる。ただし、リスコフの置換原則は、is-aの関係だけでなく、その挙動まで同じであることを求めている。
これまではis-aの関係のみを見て、継承しているのだからより具象に近いものは置き換えられてあるべきでは…？と考えていたのですが、「挙動」にまで着目すると余計なメソッドを追加したり、事前条件・事後条件に違いがあったりした心当たりがあります。
リスコフの置換原則はまだまだ理解が浅いので、出会うたびに改めて考えて理解を深めたいです。
SOLID 原則をしっかり理解したいと思った1番の項目がこれ。
テストでモックした後でインターフェースにメソッドを追加した結果、モックにもメソッドを追加する必要が出てきたときに強く違和感を感じました。
そこから「それってインターフェース分離の原則に違反しているのでは？でもどうあるべきか分からない…」というのが悩みにつながっていました。
「Clean Architecture」ではインターフェース分離の原則は再コンパイルや再デプロイを強制させることにつながるため、それを避けるために分離しよう、とのことでした。
自分が主戦場としているPHPには当てはまらない要因でしたが、そういった側面から生まれた原則だと知ることで、インターフェースの分け方を考えるときの判断材料として使えそうに感じました。
日々使っている依存関係逆転の原則。
これはだいぶ理解できていたので、再確認の意味が強かったです。
ただ、Abstract Factory パターンは聞き慣れない言葉だったので、新たな学びとなりました。
「Clean Architecture」では、SOLID 原則の他にも「コンポーネントの原則」が紹介されていました。
SOLID 原則がクラス間の設計指針を示すもので、コンポーネント間の設計指針を示すものが別途あることを初めて知りました。
いずれの原則も SOLID 原則のコンポーネント版で、ビルドやデプロイ、リリースに影響するとのことで徐々に理解を深めていきたいところです。
コンポーネントの原則を紹介する中で、安定度・抽象度の計測方法も紹介していました。
現在携わっているプロダクトの安定度・抽象度がどの程度なのか折を見て計測してみたいと思います。
「クリーンアーキテクチャ」という言葉が示すもの
「Clean Architecture」を読むまでは、クリーンアーキテクチャとはひとつの具体的なアーキテクチャを指すものと思っていました。
例えば、レイヤードアーキテクチャ、ヘキサゴナルアーキテクチャなどなど…
「Clean Architecture」を読んでみると、特に具体的なアーキテクチャは示されているわけではなく、ソフトウェアを作る上で以下を満たすようなものをクリーンアーキテクチャと分類すると理解しました。
- 関心事を分離する
- 重要なものほど抽象度を上げる
- 依存性逆転の法則により、上位のコンポーネントは下位のコンポーネントに依存しない
- フレームワーク、UI、DBなどの詳細に依存しない
- 分離した境界を越えるときは単純なデータ構造に置き換える
すなわち、ヘキサゴナルアーキテクチャもオニオンアーキテクチャもクリーンアーキテクチャということなんですね。
今まで「ヘキサゴナルアーキテクチャではこう、オニオンアーキテクチャではこう、クリーンアーキテクチャではどうだっけ？」みたいな話になることがあったのですが、若干議論がズレていたことに気付きました。
「Clean Architecture」からクリーンアーキテクチャの正しい理解が得られたとともに、そもそもクリーンアーキテクチャはどういう課題感から、何を解決したくて生まれたものなのかを知ることができました。
各設計原則を取り入れていくのはもちろんですが、それを取り入れる背景をしっかり理解し、形だけ取り入れるのではなくて具体的に「何を解決しようとして取り入れているのか」というところまでしっかり考えて取り入れていきたいです。
また、設計原則やクリーンアーキテクチャの背景にはデプロイやビルドまで視野に入れてアーキテクチャを設計しているという視点の広がりも得られました。
現在主に携わっているPHP自体はビルドという点をあまり考慮にいれる必要はないため、この設計原則とどう向き合っていけばよいかは引き続き学習課題として取り組んでいければと思います。
この記事では「Clean Architecture」を読んで得た、設計の原則とクリーンアーキテクチャの個人的な見解を紹介しました。
「クリーンアーキテクチャ」というアーキテクチャがあるものと思っていたのですが、どちらかというと概念に近く、ディレクトリ構成など具体的なものは無いという理解に落ち着きました。
開発を進めていく上でぶつかる選択に対し、提唱されてきた SOLID 原則やコンポーネントの原則を守るように選択して行った先にあるものがクリーンアーキテクチャなのかもしれませんね。
「Clean Architecture」に閉じた話でなくなるのですが、個人的に面白いと感じた点は Web は詳細として、決定を遅らせるという点でした。
「実践テスト駆動開発」では動くスケルトンから作るという点において、真っ先に Web にあたる部分から作り込んでいくかたちだった理解なので相反しているなと。
ただ、「決定を遅らせる」とあるので、インターフェースを介することで変更容易にしておけば先に作っても問題ないのかもしれませんね。
「実践テスト駆動開発」について、別の記事で紹介しているので気になる方は目を通していただけると嬉しいです。
「実践テスト駆動開発」を読んで
設計の原則とクリーンアキテクチャについては少し紹介しましたが、「Clean Architecture」について、まだまだ紹介できていない部分も多いです。
よりよいアーキテクチャを目指す上で考え方をブラッシュアップしたい方は、ぜひ一度読んてみてください。
