はじめに

本記事は、Qiita Advent Calendar における IPFactory の投稿です。
今回は、レイヤードアーキテクチャにおける各層の役割や構成を整理し、言語化してみたいと思います。

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

レイヤードアーキテクチャは、以下の4つの層から構成されるアーキテクチャパターンです。

ドメイン層
プレゼンテーション層
サービス層
インフラストラクチャ層

層間の依存関係

ドメイン層は、すべての層から参照可能な基盤となる層です。
そのほかの層は、下記の順に依存関係が形成されます。

プレゼンテーション層
サービス層
インフラストラクチャ層

この構造によって、ドメインロジックを中心に、上位層から下位層へと依存が限定的に流れるようになっています。

4層に分けるメリット

責務が明確化され、コード全体の見通しが良くなる
ファイルやフォルダ構成を整理しやすく、大規模プロジェクトでの拡張性や保守性が向上
各層が独立性を持つため、置き換えや拡張が柔軟に行える

4層に分けるデメリット

階層分割に伴い、ファイルやディレクトリが増えやすい
初期設定やプロジェクト構成に手間がかかる
定義したルールや方針のチーム内共有・徹底が難しくなりがち

では、ここから各層の役割について順に説明していきます。

ドメイン層

ドメイン層は、ビジネスロジックや業務知識をモデル化する中心的な層です。データの加工やビジネスルールの実装を担い、アプリケーション全体の根幹となります。

例：マッチングアプリの場合（あくまで一例）

Person（利用者を表すドメインモデル）
Matching（マッチング状態を表すドメインモデル）
Chatroom（チャットルームを表すドメインモデル）
など

プレゼンテーション層

プレゼンテーション層は、外部からのリクエストを受け付け、適切なサービスやインフラストラクチャ機能を呼び出す「入り口」役を担います。
Webアプリケーションであれば、Controller が代表的な例です。また、バッチ処理やコマンドラインツールもこの層に該当します。

サービス層

サービス層は、ドメイン層で定義されたビジネスロジックを組み合わせ、ひとまとまりの機能として提供する層です。
基本的な指針として「1つのサービスクラスに1つのpublicメソッド」という構成が挙げられ、ビジネスロジックを分かりやすくカプセル化することができます。

インフラストラクチャ層

インフラストラクチャ層は、DBや外部API、ストレージなどの外部システムとの接続や永続化処理を担います。
インターフェースを挟むことで、具体的な実装を容易に差し替え可能とし、柔軟な運用・保守を可能にします。

まとめ

ドメイン層：ビジネス知識・ルールをまとめた中心的な層
プレゼンテーション層：外部リクエストの受付口（UIやコントローラ）
サービス層：ドメインロジックを組み合わせ機能単位で提供する層
インフラストラクチャ層：外部システムとの通信や永続化を担う層

最後に

本記事では、レイヤードアーキテクチャを構成する4つの層について、その役割や特徴を整理しました。
実装時には、理想的なアーキテクチャパターンと実際のコードが乖離するケースも少なくありません。そのため、プロジェクト固有の方針に従うことが最も望ましい一方で、より適した構成や実装方法があれば、積極的に提案することがチーム全体の改善につながると考えます。
以上、文章のみでの説明となりましたが、読者の方々がレイヤードアーキテクチャへの理解を深める一助となれば幸いです。