🤖

第3回 フロントエンドアーキテクチャを学ぶ

2021/11/09に公開約1,800字

読んだ記事

世界一わかりやすいClean Architecture

内容の自分的解釈

超簡単にに要約してしまうと
「Clean Architectureはアーキテクチャの一例でしかないが、どんなソフトウェアにも適用できる普遍的なアーキテクチャである。」
という話。

まず第一に、クリーンアーキテクチャでよく示される図形の意味は

  • ソフトウェアを常に「Entity」「Use Case」「Controllers」「Presentation」に分けろ
  • データ、処理の流れは常に一方通行にしろ
  • PresentationはMVCに分離しろ

ということではない。
もっとも関心をおくべきことは
「依存性は外から中へだけ向かっていかなくてはならない」
ということ。
本記事で筆者が記載した抑えるべき点は3つ

  1. 依存性は、より上位のレベルの方針にのみむけよ
  2. 制御の流れと依存方向は分離しコントロールせよ
  3. 上位レベルとは相対的・再起的であることに留意せよ

とのこと。これだけを見てもわからないので具体例を見てより簡易なものに落とす。

「依存性」について

依存性については、依存する側、される側の視点にたつとわかりやすい。
依存される側に柔軟性が高いと依存する側の変更が大きい(依存される側の変更が発生しやすい→依存している側も変更が必要になってしまう)。
そのため、依存されるものは安定度が高い必要がある。
簡単な例でいうと、クリーンアーキテクチャでいうところのPresentation層は柔軟性が高い。理由はUIだから、変更があることは往々にしてあり得てしまうので。
なのでPresentation層が依存するUsecase層(ビジネスロジックと言い換えてもいい)は柔軟性が低く、普遍であるべきである。

「制御の流れと依存方向」の分離とは?

FE/BE的なところの話。
依存の方向はよく

  • ユーザーの触る画面(Presentation層、UI)
  • 内部ロジック
  • 外部へ接続する、インフラ的なロジック

と上から下の順番になってしまいがちである。
が、内部ロジックはインフラ層へ依存した場合、インフラ層は柔軟性が高い(apiの変更は往々として存在するもの)ので、依存関係としては
インフラ層→内部ロジック(usecase層)
で本来あるべきである。
ここで出現するのが「コントラクト」だそうなのだが、いまいちわからなかった。
ので、一旦上記概念は無視して、この分離を簡単にまとめると、「ロジックの分割粒度をより小さくし、依存すべきでないロジック同士の依存を断ち切り、依存の方向性を取り替える」となる。
詳しくは記事の例を読んでください。

「上位レベルとは相対的・再起的であることに留意せよ」について

これは要は視座を高めると、いろんなアプリケーションは常にClean Architecture的概念に収まるよねという話だった。

ソフトウェアアーキテクチャ3種の神器

  1. 関心の分離
  2. 疎結合
  3. 依存性逆転の原則

上位の関心(解決したい物事)を落とし込むために、個別の関心が作られる
(各層の分割、usecase, presentation, entity, infrastractureなど)

疎結合的にくっつけることで上位の関心を満たすものを作る(疎結合)
(依存関係の構築)

疎結合を依存性を適切にコントロールすることで、柔軟性を持たせる
(制御と依存関係のコントロール)

感想

抽象的な話でかなり難しかったが、「依存の方向と依存の関係性」というところが理解できてよかったと思う。
結局アーキテクチャは動きの発生しやすい部分(柔軟に動いてしまうところ)を先に理解した上で、どのように影響を小さくハンドリングしていくかが大事なのだろうと理解した。
とはいえ、この概念をアーキテクチャとして落とし込むのであれば、業務ロジックから実装の全体像、そして関心の分離までを行いつつルールを作成してく必要があるので、かなり難しい気もした。
できればこれを踏まえたディレクトリ構成などを作れるととても良い気がした。

Discussion

ログインするとコメントできます