Clean Architectureの概要を初学者向けにまとめた

2021-06-12

はじめに

この記事ではclean architectureが実際よくわからないという方向けに書いた解説記事です。本記事は「The Clean Code Blog」を参考に扱っていきます。

Clean Architectureの概念

これまで以下の有名なシステムアーキテクチャーが発明されてきました。

  • Hexagonal Architecture
  • Onion Architecture
  • Screaming Architecture
  • DCI
  • BCE

こららのシステムアーキテクチャーに共通している点として「関心ごとの分離」が挙げられます。この分離をするためにソフトウェアをレイヤーと呼ばれる層を設けて、関心ごとを分離をします。

そしてこれらのアーキテクチャーは以下の5つのルールを設けています。

  • フレームワークから独立している
  • テスタブルである
  • ユーザーインターフェースから独立している
  • データベースから独立している
  • 外部機関から独立している

この5つを実現するのがclean architectureであり、以下の図で表現されるものです。

出典元:The Clean Code Blog

この図についての解説をざっとまとめました。

  • 4つのレイヤーで構成される

    • Enterprise Business Rules
    • Application Business Rules
    • Interface Adapters
    • Frameworks & Drivers
  • 各レイヤーの依存関係の矢印は常に内側を向く「依存関係のルール」が存在する

では次に上図の各レイヤーについて解説していきます。

Enterprise Business Rules

Entities

  • 企業全体のビジネスルールをカプセル化したもの。ドメインを定義する場所でありドメインオブジェクトとも呼ばれる(ここでいうドメインというのはビジネス領域をソフトウェアの世界で表現したいものを指す)
  • 単純なアプリケーションの場合は一般的でかつ抽象的なルールをカプセル化する
  • メソッドを含んだオブジェクト、またはデータ構造と関数らを定義する
  • 各層の中で外部のものが変更されたときに変更が発生する可能性が最も低い&抽象的な層である

Application Business Rules

Use Cases

  • アプリケーション固有のビジネスルールを含みシステムのユースケースをカプセル化して実装したもの
  • Entityに対してユースケースの目的を達成するためにビジネスルールを適応するように指示を出す(ドメインオブジェクトを束ねて実際のユースケースに適応させる処理を担う)
  • Use Casesの変更がEntitiesに影響を与えることはない
  • データベース、ユーザーインターフェース、フレームワークの変更の影響を受けることはない

Interface Adapters

  • Use CasesやEntitiesに最適化されたデータをデータベースやWebに最適化されたデータ形式に変更するアダプター的なもの

Controllers

  • 外部(Frameworks and Drivers)から入力を受け取り、UseCase層が要求するデータ形式にデータを変換する

Gateways

  • Entiryの永続化をするデータベース処理を抽象化したもの
  • Interface、抽象メソッドなどを定義する
  • リポジトリなどと命名されることが多い

Presenter

  • 画面に出力をするためにView(ユーザーインターフェースに該当するコード)やデータなどを制御する

Frameworks and Drivers

  • Webフレームワーク、データベースといった最も外側の層

境界を乗り越える

  • UseCaseがPresenterを呼び出したい場合は「依存関係のルール」に反してしまう(内側のレイヤーは外側のレイヤーに依存してはいけないので)これを回避するために抽象メソッド(interface)を呼び出すことでこれを回避することができ、境界を乗り越えることができる
  • 境界を超えるデータ構造は依存関係のルールに反していないシンプルな構造でなければならない(データベースが返すデータベース固有のクエリ形式のデータなどを内側のレイヤーに渡してはいけない。外側のレイヤーから渡されるデータ構造がデータベース依存の構造になっており、依存関係のルールに反してしまうから)

おわりに

概念やルールばかりで抽象的な内容になってしまいましたが「The Clean Code Blog」に書かれていたことやclean architectureの概要はまとめられたかなと思います。誤り等を見つけて下さった方はお手数ですが@katuoまでご連絡いただければ嬉しいです。最後までお読みいただきありがとうございました。

参考文献:

KATUO
Software Engineer