Java（特に Spring Boot）でアプリを作ると、ほぼ必ず登場するのが Controller / Service / Repository / Request / Response といったレイヤー構造です。
最初は「名前は聞くけど、どれが何をするの？」という状態になりがち。
しかし、これらの役割をしっかり理解すると 設計・保守・テストが一気に楽になります。
この記事では構成図付きで、それぞれの役割を初心者にもわかりやすく解説します。
全体の構成図（Request → Response の流れ）
以下が典型的な Spring Boot の構成です。
使用するデータ構造は次のとおり。
Request DTO：クライアント → Controller
Response DTO：Controller → クライアント
1. Controller（リクエスト受付・レスポンス返却）
Controller は HTTP リクエストを受け取り、レスポンスを返す役割 を持つ層です。
URL のルーティング
Request DTO の受け取り
Service の呼び出し
Response DTO に変換して返却
コード例
@PostMapping("/users")
public UserResponse createUser(@RequestBody UserRequest request) {
return userService.create(request);
}
📌 Controllerの注意点
ビジネスロジックは書かない
データベース操作は絶対に直接書かない
2. Service（ビジネスロジック担当）
アプリケーションの核となる層で、業務ロジックを一手に引き受ける 役割です。
条件処理・計算などのビジネスロジック
Repository の呼び出し
トランザクション管理（@Transactional）
コード例
@Transactional
public UserResponse create(UserRequest request) {
User user = new User(request.getName());
userRepository.save(user);
return new UserResponse(user);
}
📌 Service の注意点
Controller と Repository の中継役ではなく “ロジックの本体”
複雑な処理はここに集中させる
3. Repository（データアクセス担当）
Repository は DBとの通信を担当 する場所です。
Spring Data JPA では、CRUD のほとんどを自動生成してくれます。
データ検索
登録
更新
削除
コード例
public interface UserRepository extends JpaRepository<User, Long> {}
📌 Repository の注意点
Repository を Controller から直接呼ばない
DB の役割がこの層にまとまるため、変更に強くなる
4. Request DTO（入力データ）
クライアント → Controller への データの受け皿。
public class UserRequest {
@NotNull
private String name;
}
Request DTO の役割
入力データの構造を定義
バリデーション（@NotNull など）を付与
Entity を直接受け取らない安全性
5. Response DTO（出力データ）
Controller → クライアント へ返す 出力専用データ。
public class UserResponse {
private Long id;
private String name;
public UserResponse(User user) {
this.id = user.getId();
this.name = user.getName();
}
}
Response DTO の役割
出力する情報を限定できる
API の仕様を整えやすい
Entity の内部情報を外に漏らさない
🧠 なぜこんなに層を分けるのか？
1. 責務が明確になり読みやすい
どの処理がどこに書かれているべきかが明確。
2. テストがしやすい
Service 単体、Controller 単体など、テストが分離できる。
3. 変更に強い
DB を変えても Repository だけ直せばOK
API の仕様を変えても Request/Response の変更だけで済む
4. チーム開発に向いている
役割が明確なので、複数人で分担しやすい。
✔ まとめ（構造を完全理解するポイント）
Controller：受け取り・返す
Service：ビジネスロジック
Repository：DBアクセス
Request：外からのデータ
Response：外に返すデータ
この構造を押さえておくと、Springアプリの理解が格段に進みます。
特に Service を “ロジックの中心” として正しく使えるようになると、可読性・保守性が一気に向上します。