はじめに
本記事は、Qiita Advent Calendar における IPFactory の投稿です。
今回は、レイヤードアーキテクチャにおける各層の役割や構成を整理し、言語化してみたいと思います。
レイヤードアーキテクチャとは
レイヤードアーキテクチャは、以下の4つの層から構成されるアーキテクチャパターンです。
- ドメイン層
- プレゼンテーション層
- サービス層
- インフラストラクチャ層
層間の依存関係
ドメイン層は、すべての層から参照可能な基盤となる層です。
そのほかの層は、下記の順に依存関係が形成されます。
- プレゼンテーション層
- サービス層
- インフラストラクチャ層
この構造によって、ドメインロジックを中心に、上位層から下位層へと依存が限定的に流れるようになっています。
4層に分けるメリット
- 責務が明確化され、コード全体の見通しが良くなる
- ファイルやフォルダ構成を整理しやすく、大規模プロジェクトでの拡張性や保守性が向上
- 各層が独立性を持つため、置き換えや拡張が柔軟に行える
4層に分けるデメリット
- 階層分割に伴い、ファイルやディレクトリが増えやすい
- 初期設定やプロジェクト構成に手間がかかる
- 定義したルールや方針のチーム内共有・徹底が難しくなりがち
では、ここから各層の役割について順に説明していきます。
ドメイン層
ドメイン層は、ビジネスロジックや業務知識をモデル化する中心的な層です。データの加工やビジネスルールの実装を担い、アプリケーション全体の根幹となります。
例：マッチングアプリの場合（あくまで一例）
- Person（利用者を表すドメインモデル）
- Matching（マッチング状態を表すドメインモデル）
- Chatroom（チャットルームを表すドメインモデル）
など
プレゼンテーション層
プレゼンテーション層は、外部からのリクエストを受け付け、適切なサービスやインフラストラクチャ機能を呼び出す「入り口」役を担います。
Webアプリケーションであれば、Controller が代表的な例です。また、バッチ処理やコマンドラインツールもこの層に該当します。
サービス層
サービス層は、ドメイン層で定義されたビジネスロジックを組み合わせ、ひとまとまりの機能として提供する層です。
基本的な指針として「1つのサービスクラスに1つのpublicメソッド」という構成が挙げられ、ビジネスロジックを分かりやすくカプセル化することができます。
インフラストラクチャ層
インフラストラクチャ層は、DBや外部API、ストレージなどの外部システムとの接続や永続化処理を担います。
インターフェースを挟むことで、具体的な実装を容易に差し替え可能とし、柔軟な運用・保守を可能にします。
まとめ
- ドメイン層：ビジネス知識・ルールをまとめた中心的な層
- プレゼンテーション層：外部リクエストの受付口（UIやコントローラ）
- サービス層：ドメインロジックを組み合わせ機能単位で提供する層
- インフラストラクチャ層：外部システムとの通信や永続化を担う層
最後に
本記事では、レイヤードアーキテクチャを構成する4つの層について、その役割や特徴を整理しました。
実装時には、理想的なアーキテクチャパターンと実際のコードが乖離するケースも少なくありません。そのため、プロジェクト固有の方針に従うことが最も望ましい一方で、より適した構成や実装方法があれば、積極的に提案することがチーム全体の改善につながると考えます。
以上、文章のみでの説明となりましたが、読者の方々がレイヤードアーキテクチャへの理解を深める一助となれば幸いです。