Clean Architectureって何かを考えてみた
はじめに
Clean Architectureがどんな概念なのか感じたことをざっくり書くだけの記事()です。
正直、SOLIDとか技術的なことはググったら良い記事が沢山出るのであまり書きません。
技術的なことよりかは、何の意味があるのかのような思想的なことを書きます。
要約
- 依存に方向性を持たせて変更の影響をコントロール
- 本質的でない処理からビジネスロジックへ依存を一方向にすることで変更の影響の伝搬を及ぼさないようにする
Clean Architectureとは?
Clean Architectureというと同心円上に4階層に区切られたあの親の顔より見た図が思い浮かびます。
しかし、実態はレイヤードアーキテクチャの一種です。
視覚的にわかりやすいからあの図なだけで、4階層である必要も円であることも重要ではないです。
そして、層間では依存の矢印が1方向に統一されていて外部から内部にしか向けられない。
つまり依存性を外 -> 内にコントロールしていることになります。
このコントロールにより外側の変更の影響を内側に伝搬させないようにするのがClean Architectureの意義だと考えています。
では外側と内側とは何かとなりますが、その前にレイヤードアーキテクチャを説明します。
レイヤードアーキテクチャ
レイヤードアーキテクチャは責務毎に層を区切って設計するアーキテクチャです。分かり易いのは3レイヤーアーキテクチャでしょうか。
Webバックエンドでよく見る例はプレゼンテーション・ビジネスロジック・データアクセス層による構成です。
その中でもアプリケーションのビジネスロジックはコアであり最も重要な部分です。あとはビジネスロジックを実行するための周辺的な処理とみなせます。
3レイヤーアーキテクチャ
ですが、このような依存関係ではデータアクセスに変更があった場合に影響がビジネスロジックに伝搬する可能性があります。
依存関係があると依存する側がされる側の変更に影響を受けるのは納得して頂けると思います。
依存による変更の伝搬図
外側と内側
依存の外側と内側とは何かという話でしたが、アプリケーションを構成要素毎に分離した時、アプリケーションにとってより本質的な要素を内側に据えるという話です。
プレゼンター・データアクセスとビジネスロジックはどっちの方がアプリケーションにとって本質的な処理でしょうか?当然、ビジネスロジックでしょう。
プレゼンター・データアクセスはアプリケーションを構成する上で必須ですし重要ですが、本質的なものでありません。そしてこのような要素は、技術的なものに深く関わるため「実装」などと呼ばれることがあります。(データアクセスならORMやHTTPクライアントなど)
そのため、各構成要素を比較した際、アプリケーションにとってどちらがより本質的な処理なのかという相対的な判断が必要になると考えています。
よって、プレゼンター・データアクセス -> ビジネスロジックという依存関係にする必要があります。
本質的というすごいフワっとした考え方になってしまうのですが、こればかりは構築するアプリケーションによって変わってくるので適宜判断するしかないと考えてます。
とは言っても、現実的にはビジネスロジックからデータアクセスを実行しなければならない上に、依存性を持たせないで実現する必要があります。
そのために、抽象化による依存のコントロールが必要になります。
抽象化による依存のコントロール
ビジネスロジックで使用するデータの操作に必要な入出力はビジネスロジックの層で決まるはずです。
入出力の型さえ守ってくれれば、実際にどのような技術・サービス・ツールを使っていようがビジネスロジックには関係ありません。
Goではインターフェースを用いて入出力の定義のみを行い、実装を抽象化します。
ビジネスロジックが依存する実装(データアクセス)へのインターフェース(インターフェースB)を定義する。ビジネスロジックはそのインターフェースに依存。実装はインターフェースに依存するので結果的にビジネスロジックから実装への依存性はなくなります。
具体的な実装方法に関しては、プログラミング言語と依存性注入やDependency Injection, IDコンテナライブラリなどで検索してください。大量に記事が出てきます。
インターフェースによる依存のコントロール
ビジネスロジックは現実世界のビジネスの概念やルール・手順を記述するレイヤーです。
だからこそアプリケーションのコアであり、それがデータの取得方法が変わったからビジネスの処理を変更するというのはおかしな話ではないでしょうか。逆にビジネスが変わったから取得に必要なデータや取得するデータが変わるのは変な話ではないでしょう。
結論
- アプリケーションにおいて変更の影響が伝わるのは依存関係と依存方向による
- アプリケーションにとって本質的な処理とそれを実行ための実装を分ける
- 依存関係は実装から本質的な処理に向けることで変更の影響をコントロール
あとがき
初めて記事を書いたため、読みづらい・意味不明などの至らない点が多くあると思いますが学習を続けてより良い記事を書けるようにしていきたいです。
またマサカリなどもどんどん投げて頂けるとありがたいです。
参照
表情アイコン 著作者：rawpixel.com/出典：Freepik
Discussion