背景
解決策
以下の2つのパターンのいずれかを、メリットデメリットを考慮して決定する
緩い(Relaxed)レイヤー化アーキテクチャ
-
規約
- 層を跨いだ依存を許容する
- プレゼンテーション層はユースケース層を跨いだドメイン層のへの依存を許可する
![Untitled](https://s3-us-west-2.amazonaws.com/secure.notion-static.com/48e05521-0e04-44d8-af6f-a3fbc34f80f6/Untitled.png)
-
メリット
- 区分値やIDなどの値オブジェクトを使用してユースケースに渡すことが可能になり、タイプセーフになる
厳しい(Strict)レイヤー化アーキテクチャ
-
概要
- すぐ下の層にしか依存してはいけない
- プレゼンテーション層からはユースケース層への依存のみで、ドメイン層への依存を許可しない。
![Untitled](https://s3-us-west-2.amazonaws.com/secure.notion-static.com/297d40a9-edd7-4a26-b7c3-97c8e5767c99/Untitled.png)
-
メリット
- プレゼンテーション層でドメインオブジェクトを使えなくなり、ユースケース層に書くべき実装がプレゼンテーション層に漏出することを強制的に防げる
それぞれ、デメリットはもう一方の選択肢の逆となります。
筆者の普段の選択
- 筆者は普段緩いレイヤー化を採用しています。
- ユースケース層のメソッドの引数はIDクラスや区分値はタイプセーフな方が可読性、安全性の観点から利点があるためです。ここがプリミティブになるとかなり見通しの悪いコードになってしまいます。
- プレゼンテーション層でユースケースを組み立てるような実装ができてしまうというデメリットは、強制力はありませんが規約やレビュー、教育でカバーする方針を取っています。
参考文献
この記事は何か