はじめに
Spring Boot のコードを書いていると、
Controller / Service / Repository という
3 つの層をよく目にします。
「なんとなく分けてるけど、理由は？」
「三層アーキテクチャって何？」
「どこに何を書けばいいの？」
そんな疑問を持つ方に向けて、 三層アーキテクチャを
やさしく・実務寄り で整理していきます。
まずは全体像から見ていきましょう。
三層アーキテクチャとは
一言でいうと、
「役割ごとにコードを 3 つの層に分けて、見通しと保守性を高める設計」
です。
- Presentation（表示・受付）
- Application（業務処理）
- Data Access（データアクセス）
Spring Boot では、
Controller / Service / Repository
として実装されることが多いです。
三層アーキテクチャの全体像
┌──────────────────────┐
│ Controller（表示層） │ ← リクエストを受け取る
└───────────┬──────────┘
│
┌───────────▼──────────┐
│ Service（業務層） │ ← ビジネスロジック
└───────────┬──────────┘
│
┌───────────▼──────────┐
│ Repository（データ層） │ ← DB とのやり取り
└──────────────────────┘
この 3 つが役割分担することで、
コードが読みやすく、変更に強くなります。
Controller（表示層）
役割
- リクエストを受け取る
- パラメータを受け取る
- Service を呼び出す
- レスポンスを返す
書かないこと
- 業務ロジック
- DB アクセス
- 計算処理
例
@RestController
public class UserController {
private final UserService service;
public UserController(UserService service) {
this.service = service;
}
@GetMapping("/users/{id}")
public UserResponse getUser(@PathVariable Long id) {
return service.findUser(id);
}
}Controller は“受付係”です。
Service（業務層）
役割
- ビジネスロジック
- 複数の Repository を組み合わせる
- トランザクション管理
- バリデーション（業務的なもの）
書かないこと
- HTTP の処理
- DB の直接操作
例
@Service
public class UserService {
private final UserRepository repository;
public UserService(UserRepository repository) {
this.repository = repository;
}
public UserResponse findUser(Long id) {
User user = repository.findById(id)
.orElseThrow(() -> new UserNotFoundException("not found"));
return new UserResponse(user.getName(), user.getAge());
}
}Service は“司令塔”です。
Repository（データ層）
役割
- DB とのやり取り
- SQL / ORM の実行
- データの永続化
書かないこと
- 業務ロジック
- HTTP の処理
例
@Repository
public interface UserRepository extends JpaRepository<User, Long> {
}Repository は“データの窓口”です。
三層アーキテクチャを使うメリット
役割が明確になる
Controller にロジックを書かない、
Service に SQL を書かない、
というルールでコードが整理されます。
テストしやすい
- Service の単体テスト
- Repository のテスト
- Controller のテスト
層ごとにテストできるため、品質が上がります。
変更に強い
- DB を変えても Controller は影響を受けない
- 画面を変えても Service はそのまま
- ロジックを変えても Repository はそのまま
層が分かれていることで影響範囲が小さくなります。
実務でよくあるアンチパターン
Controller にロジックを書いてしまう
→ 画面が増えると地獄になります。
Service がただの“中継役”になる
→ ロジックが薄すぎると層の意味がなくなります。
Repository に業務ロジックを書く
→ DB に依存した設計になり、変更に弱くなります。
三層アーキテクチャをもっと活かすポイント
DTO を使う
Controller と Service の間で
リクエスト / レスポンスを明確にできます。
例外クラスを使う
Service 層で例外を投げ、
ControllerAdvice でまとめて処理できます。
トランザクション管理
Service 層に @Transactional を付けるのが基本です。
まとめ
三層アーキテクチャとは、
「Controller / Service / Repository に役割を分ける設計」
です。
- Controller → 受付
- Service → 業務ロジック
- Repository → データアクセス
- 役割が明確になり、保守性が上がる
- テストしやすく、変更に強い
難しく聞こえますが、
「受付・司令塔・データ係」
と理解できれば十分です。
三層アーキテクチャを理解すると、
Spring のコードが一気に読みやすくなります。
役割が整理されるだけで、設計の迷いが減り、
開発がとてもスムーズになります。
あなたの開発が、今日より少しだけ楽になりますように。
受付係と司令塔とデータ係…役割分担ってかわいいね。
コメント