レイヤードアーキテクチャ

レイヤードアーキテクチャ

執筆済 ソフトウェア開発設計

責務ごとに水平な層に分け、上の層が下の層を使う構造。

[プレゼンテーション]   UI、入出力
        ↓
[アプリケーション]     ユースケースの手順
        ↓
[ドメイン]             業務ロジック、規則
        ↓
[インフラストラクチャ] DB、外部 API、ファイル

規則#

  • 上の層は下の層を呼べる
  • 下の層は上の層を知らない
  • 層を飛び越さない（厳密な層化の場合）

依存の向きが一方向であることが本質。 これにより、上を変えても下は影響を受けない。

利点と限界#

利点 限界
責務が明確 ドメインがインフラに依存してしまう
理解しやすい 1 機能の追加で全層を触る
定番なので伝わる 層をまたぐ変換のコード量

最大の問題が 1 つ目。 素朴な層化では、 ドメイン層が「DB を使う」という形で インフラに依存する。

業務の規則が、DB の都合に縛られる。

ドメイン → インフラ（DB）    ← これが問題

依存性逆転による解決#

ドメイン層にインタフェースを置く。

[ドメイン]  Repository（抽象）を定義する
     ↑
[インフラ]  Repository を実装する

矢印が逆向きになり、 ドメインが最も安定した中心になる。

この考えを徹底したのが クリーンアーキテクチャや ヘキサゴナルアーキテクチャ。

規模に応じて#

規模 目安
小 層を作らない。素直に書く
中 UI / ロジック / データ の 3 層
大 明示的な層 + 依存性逆転

層の数は目的ではない。

参考文献#

  • Martin Fowler. Patterns of Enterprise Application Architecture. Addison-Wesley, 2002.
  • Robert C. Martin. Clean Architecture: A Craftsman’s Guide to Software Structure and Design. Prentice Hall, 2017.
  • Eric Evans. Domain-Driven Design. Addison-Wesley, 2003.