背景

• レイヤー化したアーキテクチャ(オニオンアーキテクチャ、クリーンアーキテクチャ等)の場合、層を跨いだ依存を許すのかどうか判断の必要がある

  

解決策

以下の2つのパターンのいずれかを、メリットデメリットを考慮して決定する

緩い(Relaxed)レイヤー化アーキテクチャ

• 規約

  • 層を跨いだ依存を許容する
  • プレゼンテーション層はユースケース層を跨いだドメイン層のへの依存を許可する

  

• メリット

  • 区分値やIDなどの値オブジェクトを使用してユースケースに渡すことが可能になり、タイプセーフになる

厳しい(Strict)レイヤー化アーキテクチャ

• 概要

  • すぐ下の層にしか依存してはいけない
  • プレゼンテーション層からはユースケース層への依存のみで、ドメイン層への依存を許可しない。

  

• メリット

  • プレゼンテーション層でドメインオブジェクトを使えなくなり、ユースケース層に書くべき実装がプレゼンテーション層に漏出することを強制的に防げる

それぞれ、デメリットはもう一方の選択肢の逆となります。

筆者の普段の選択

• 筆者は普段緩いレイヤー化を採用しています。
• ユースケース層のメソッドの引数はIDクラスや区分値はタイプセーフな方が可読性、安全性の観点から利点があるためです。ここがプリミティブになるとかなり見通しの悪いコードになってしまいます。
• プレゼンテーション層でユースケースを組み立てるような実装ができてしまうというデメリットは、強制力はありませんが規約やレビュー、教育でカバーする方針を取っています。

参考文献

• https://www.thinktocode.com/2018/07/05/layered-architecture/

この記事は何か

• トップページの説明をご覧ください