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

DDDの文脈から書かれている

基本的にどのアーキテクチャも一貫して責務を適切に設定して依存関係を明確にするという目的があります

https://qiita-user-contents.imgix.net/https%3A%2F%2Fqiita-image-store.s3.ap-northeast-1.amazonaws.com%2F0%2F66063%2Fd85e23fb-0746-d329-df32-e24834424876.png?ixlib=rb-1.2.2&auto=format&gif-q=60&q=75&w=1400&fit=max&s=a55d18a76ea903803197c21115b03b43

UI層からDomain層を触ってはいけない

レイヤは跨がない

Application層ではドメインオブジェクトの振る舞いを経由して、ドメインオブジェクトに変更を加える

直接に値の更新はしない

利点

UI層とInfrastructure層を切り替えやすい

最も大事なドメインロジックとユースケースが隔離されている

欠点

コードの量が増える

やりたいことに対してオーバーテクノロジーになりうる？

チーム開発で習熟度の差があると大変

ドメインロジックがInfrastructure層の影響を受ける

一言でいうと、アプリケーションを作る際にそれを構成する部品を、それぞれ責務が定義された論理的なグループにまとめて整理し、それぞれのグループ間のやり取りの仕方を決めておこうという事です。

メリット

コードの何がどこにあるか把握しやすくなる

変更が特定の層で閉じる

この記事ではプレゼンテーション層、ビジネスロジック層、データアクセス層の3層で説明している

ドメインとユースケースが同じ層

ビジネスロジック

そのシステムで業務を表現するモデルや処理が置かれる。業務的なバリデーションやルールの適応など。

設計のポイント

中間のレイヤーを飛ばして下のレイヤーをつかったほうがいいとき

パフォーマンス上の理由

レイヤー間での依存関係を無視してもいいとき

下位のモジュールと上位のモジュールを1:1で定義する

下位モジュールが上位モジュールの都合で作られる、という違反

https://cdn-ak.f.st-hatena.com/images/fotolife/e/ea54595/20190416/20190416160826.jpg

レイヤーの数の増減

https://cdn-ak.f.st-hatena.com/images/fotolife/e/ea54595/20190416/20190416161717.jpg

レイヤー外の横断的関心事 (Cross Cutting Concern)

ロギング、キャッシュ、セキュリティなどはレイヤーを跨ぐ

https://cdn-ak.f.st-hatena.com/images/fotolife/e/ea54595/20190416/20190416162548.jpg

単一のライブラリとして、どのレイヤーからも疎にしておく

導入時のポイント

プロトタイピング

本当にそれで開発していけるか検証する

レイヤーの責務の明文化とその浸透策の検討

開発者全員がレイヤーを認識する必要がある

継続的に変更しやすいようにしておく

後からレイヤーの差し込みや部品の追加などができないような縛りは入れない方がよい

Patterns of Enterprise Application Archtecture にもありますが、「レイヤードアーキテクチャを行う上で最も難しいのは、必要なレイヤーと各レイヤーが行うべき内容を決定する事である」とあります。