はじめに
Spring アプリケーションにおける「層（レイヤー）」の役割を、初学者の私なりに整理しました。
よく使われる主要な層に加えて、Presenter や Client 層についても簡単に紹介します。
対象者
- あらためて「層（レイヤー）」について簡易的に学びたい人
- Springについて初学者
- 知識をふやしたい人
主要な層（Layered Architecture）
1. Presentation / Controller 層
- クライアント（フロントエンドや API 呼び出し）からの HTTP リクエストを受け取る、最初の入り口
- @Controller や @RestController を使って定義する
- URL・パラメータの受け渡し、初期エラー応答（認証・パラメータチェック）などを行う（実際の処理は Service 層に渡している）
2. Service（ビジネスロジック）層
- Controller から渡されたデータを元に、業務処理や入力チェック・変換・ロジック制御を行う
- @Service で定義し、処理が複数の Repository や外部 API を跨る時に中心となる層
3. Repository（Persistence / DAO）層
- データベースへのアクセスを行う（CRUD 処理）
- @Repository を使い、例外の変換（二重チェック）などの特別な処理も提供される
4. Database 層
- 永続データを保存する本体（例：MySQL、PostgreSQL、MongoDB など）
- アプリケーションコードから直接触ることは少なく、Repository 経由で間接的に操作される
他によく登場する層・概念
Presenter 層
- Use Case（Service 処理）からの出力を、クライアントに返す適切な形式（JSON など）に整形する役割
- Clean Architecture や DDD では明確に分かれていることがある
Client層（外部API呼出し）
- 自分のアプリから他の API を呼び出す処理をまとめた層で、Spring では RestTemplate や WebClient を使い、通常は Service 層から呼び出す
- 外部サービスを扱う専用の「クライアントクラス」を作ることで責務を分離している
Facade 層（時として使われる）
- 複数の Service ロジックをまとめて Controller に提供する役割を果たす層
- Service 層を単純にまとめたい場面や、複数処理の調整を一箇所で行いたいときに使われる
| 層名 | 使う注釈 | 主な責務 | メリット |
|---|---|---|---|
| Presenter（optional） | 自作または @Component
|
データ整理・JSON変換、ビュー出力形式への加工など | ロジック分離＆統一フォーマット管理 |
| Controller |
@Controller / @RestController
|
リクエスト入口／エンドポイント処理 | HTTP とアプリ処理の分離、役割が明確になる |
| Service | @Service |
ビジネスロジックの実装、外部連携処理など | 処理の集中化、各層の責務が明確 |
| Client（外部） |
@Component 等 |
外部 API と通信し、DTO を定義して返す | API 呼び出しのコードを整理、再利用しやすく |
| Repository | @Repository |
DB 操作（CRUD）を担当 | DB 操作の抽象化と例外処理の統一 |
| Entity / Domain | @Entity |
アプリの中心データ（ユーザー、注文など）を表現するモデル | ドメインロジックの中心、マッピングの中心概念 |
おまけ（層をわける理由）
- 責任を分割して管理しやすくするため（Separation of Concerns）
- テストやリファクタリングがしやすくなる（モジュール毎に差し替えが可能）
- 保守性、拡張性を高め、どこに何を書くかが明快になる
参考