Spring Boot 실무 프로젝트 폴더 구조: 계층형 vs 도메인 중심

 

---

Spring Boot 실무 프로젝트 폴더 구조 설계 가이드

백엔드 프로젝트를 설계할 때 가장 중요한 초기 작업 중 하나는 폴더 구조를 설정하는 것입니다. 올바른 폴더 구조는 코드의 가독성과 유지보수성을 높이고, 팀 간 협업을 원활하게 만듭니다. 이번 글에서는 Spring Boot 프로젝트에서 주로 사용되는 계층형 구조와 도메인 중심 구조(DDD)를 비교하고, 실무에서 고려해야 할 사항을 다룹니다.

---

1. 계층형 구조

📂 기본 개념

계층형 구조는 프로젝트를 기능별로 분리한 방식입니다. 컨트롤러, 서비스, 레포지토리 등 각 계층별로 관련된 클래스를 분리하여 관리합니다. 이는 간단한 애플리케이션이나 작은 규모의 프로젝트에서 널리 사용됩니다.

📁 폴더 구조 예시

src/main/java
├── controller    // API 요청 처리
├── service       // 비즈니스 로직
├── repository    // 데이터베이스 접근
├── domain        // 엔티티 클래스
└── dto           // 데이터 전송 객체

✅ 장점

• 직관적이고 이해하기 쉬움: 초보 개발자도 쉽게 이해하고 사용할 수 있는 구조입니다.
• 빠른 개발 가능: 초기 설정이 간단하여 빠르게 개발을 시작할 수 있습니다.

❌ 단점

• 확장성의 한계: 프로젝트가 커질수록 각 계층에 클래스가 많아져 관리가 어려워질 수 있습니다.
• 도메인 간 의존성 관리 어려움: 복잡한 비즈니스 로직에서는 코드의 종속 관계가 증가할 가능성이 큽니다.

💡 사용 사례

• 규모가 작은 프로젝트
• 학습용 또는 단기 프로젝트

---

2. 도메인 중심 구조 (DDD)

📂 기본 개념

도메인 중심 설계(Domain-Driven Design, DDD)는 비즈니스 로직 중심으로 관련 코드를 하나의 도메인 단위로 묶는 방식입니다. 대규모 프로젝트나 복잡한 비즈니스 로직이 포함된 프로젝트에서 특히 유용합니다.

📁 폴더 구조 예시

src/main/java
└── domain
    ├── user
    │   ├── UserController.java
    │   ├── UserService.java
    │   ├── UserRepository.java
    │   ├── User.java
    │   └── UserDto.java
    ├── product
    │   ├── ProductController.java
    │   ├── ProductService.java
    │   ├── ProductRepository.java
    │   ├── Product.java
    │   └── ProductDto.java

✅ 장점

• 확장성과 유지보수성 우수: 도메인 단위로 클래스를 묶어 관리하기 때문에 새로운 도메인을 추가하거나 변경하기가 쉽습니다.
• 독립적이고 모듈화된 코드: 도메인 간 종속성을 줄여 코드의 재사용성과 독립성을 높일 수 있습니다.

❌ 단점

• 초기 설계 시간 필요: 도메인 분석과 구조 설계에 시간이 많이 소요됩니다.
• 학습 곡선: 팀원이 DDD에 익숙하지 않다면 도입에 어려움이 있을 수 있습니다.

💡 사용 사례

• 대규모 프로젝트
• 복잡한 비즈니스 로직이 포함된 프로젝트
• 장기적인 확장성을 고려해야 하는 경우

---

3. 실무에서 DTO 설계 팁

🚩 강의에서 사용하는 방식

간단한 예제에서는 DTO를 Controller 내부의 static 클래스로 정의하는 방식을 종종 볼 수 있습니다.

@RestController
public class UserController {
    @PostMapping("/users")
    public ResponseEntity<UserResponse> createUser(@RequestBody UserRequest request) {
        // 비즈니스 로직 수행
    }

    static class UserRequest {
        private String name;
        private String email;
    }

    static class UserResponse {
        private Long id;
        private String name;
    }
}

✅ 실무에서 권장되는 방식

실무에서는 DTO를 별도의 dto 패키지로 분리하여 관리하는 것이 일반적입니다.

src/main/java
└── dto
    ├── UserRequest.java
    └── UserResponse.java

이 방식은 다음과 같은 장점을 제공합니다:

1. 가독성 증가: DTO가 컨트롤러 코드에서 분리되어 깔끔한 구조 유지.
2. 재사용성 증가: 여러 컨트롤러에서 동일한 DTO를 활용 가능.

---

4. 결론: 프로젝트에 적합한 구조 선택

🔑 선택 기준

1. 프로젝트 규모: 작은 프로젝트는 계층형 구조, 대규모 프로젝트는 도메인 중심 구조를 고려하세요.
2. 팀의 경험: 팀원이 DDD에 익숙하다면 도메인 중심 설계를, 아니라면 계층형 구조로 시작하세요.
3. 유지보수성: 장기적으로 확장 가능한 구조가 필요하다면 도메인 중심 설계를 권장합니다.

📌 추천 조합

초기에 계층형 구조로 시작하고, 프로젝트가 확장됨에 따라 도메인 중심 구조로 리팩터링하는 것도 좋은 방법입니다.

---

이 글이 여러분의 프로젝트 구조 설계에 도움이 되었다면, 좋아요와 댓글로 의견을 공유해 주세요! 😊

 

 

---

Disclaimer: 본 블로그의 정보는 개인의 단순 참고 및 기록용으로 작성된 것이며, 개인적인 조사와 생각을 담은 내용이기에 오류가 있거나 편향된 내용이 있을 수 있습니다.