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

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

レイヤードアーキテクチャは、システムを役割ごとの「層(レイヤー)」に 水平に分割する、最も古典的で広く使われているアーキテクチャパターンです。それぞれの層は特定の関心事だけを 担当し、隣接する層とだけやり取りします。

目的は関心の分離です。「画面の表示方法」と「ビジネスルール」と 「データの永続化方法」を1つのクラスに混在させると、どれか1つを変更したいだけなのに全体を読み解く必要が 出てきます。層を分けることで、変更の影響範囲を局所化できます。

典型的な4層構成

層の数や名前は文献によって異なりますが、代表的には次の4層に分けられます。

+-------------------------------------+
|  1. Presentation Layer               |
+-------------------------------------+
|  2. Application Layer                |
+-------------------------------------+
|  3. Domain Layer                     |
+-------------------------------------+
|  4. Infrastructure Layer             |
+-------------------------------------+

  depends on (top -> bottom, one direction only)

依存の向きのルール

レイヤードアーキテクチャの核となるルールは単純です。上位層は下位層を呼び出せるが、 下位層は上位層のことを一切知らない、という一方向の依存です。

擬似コードで表すと次のような呼び出し関係になります。

// OK: 上位層 -> 下位層
function PresentationHandler(request):
    result = ApplicationService.execute(request)
    return renderResponse(result)

function ApplicationService.execute(input):
    entity = DomainRule.apply(input)
    InfrastructureRepository.save(entity)

// NG: 下位層 -> 上位層への逆依存
function InfrastructureRepository.save(entity):
    PresentationHandler.notifyUser(entity)  // 違反: 下位層が上位層を知っている

この逆依存が発生すると、Infrastructure層の変更がPresentation層に波及したり、 Infrastructure層を単体でテストできなくなったりします。

メリットとトレードオフ

レイヤードアーキテクチャは万能ではなく、次のようなメリットと代償を天秤にかけて採用します。