일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 |
- docker
- 도커로db설치
- Nest.js
- gcp ssh vm
- 스프링부트패키지구조
- jwt장점
- 맥북개발환경
- ssh 포트 변경
- macos개발환경
- gcp ssh 포트 변경
- docker mysql설치하기
- nest passport
- ssh 연결 방법
- vm ssh port
- vm ssh 포트 변경
- ssh연결
- 패키지구조
- InnerJoinMapOne
- jdk설치
- nest jwt
- db로컬설치
- How to Join Tables Without Relations in TypeORM
- vm ssh 포트
- nest login
- nest authentication
- JWT
- Nest.js login
- Nest.js 로그인
- JWT쓰는이유
- local database
- Today
- Total
Seize the day
[Spring Boot] 패키지 구조: 계층형 vs 도메인형과 도메인 중심 설계(DDD) 본문
Spring Boot로 백엔드 개발을 시작하면서 가장 먼저 찾아보게 된 패키지 구조.
과거에는 Spring Boot 기본 구조도 그렇고, 엔터프라이즈 개발에서는 레이어드 아키텍처(Controller → Service → Repository)를 많이 사용한다. 특히, 전통적인 기업 시스템(ERP, CRM 등)에서는 여전히 Layered Architecture를 쓰고 있다.
최근에는 모듈화(컴포넌트화), 도메인 중심 설계(DDD)를 추구하는 경우가 늘어나며 복잡한 서비스는 계층(layer)보다 도메인(domain)이나 모듈(module)을 중심으로 나누는 게 관리가 훨씬 편리하다. 특히, 마이크로서비스 아키텍처(MSA)를 고려하면 더더욱 그렇다.
Spring Boot 패키지 구조는 크게 계층형 구조와 도메인형 구조로 나뉜다.
1. 계층형 구조 (Layered Architecture)
📁 구조 예시
└── com.example.project
├── controller
├── service
├── repository
└── domain (entity)
역할(Controller, Service, Repository)에 따라 레이어를 나눠 MVC 패턴과 유사하다.
Spring 기본 예제에서 흔히 사용하는 구조로, 직관적이다.
단점은 기능이 복잡해질 수록 관심사가 분리되지 않고 서로 얽히기 쉽고, 특정 도메인 기능을 파악하려면 여러 폴더를 오가야한다.
2. 도메인형 구조 (Domain-centric Architecture)
📁 구조 예시
└── com.example.project
└── user
├── controller
│ └── UserController.java
├── service
│ └── UserService.java
├── repository
│ └── UserRepository.java
├── entity
│ └── User.java
└── dto
├── UserRequestDTO.java
└── UserResponseDTO.java
기능(도메인) 단위로 관련된 코드를 한 폴더에 묶는 구조로, 필요한 코드가 한 폴더에 모여 있어 가독성과 유지보수성이 높다.
단점은 애플리케이션의 전반적인 흐름을 한눈에 파악하기가 어렵고, 초반 설계에 고민이 필요하다.
찾아보면 계층형 구조는 규모가 작고, 도메인이 적은 경우를 추천하고 도메인형 구조는 규모가 크고 도메인이 많은 경우를 추천한다.
이번에 사이드프로젝트를 진행하면서, 개인적으로 나의 선택은?!
나는 NestJS에서 모듈 기반의 구조에 익숙해져 있어서, Spring에서도 자연스럽게 도메인형 구조를 선택했다. 코드를 찾기 쉽고, 새로운 기능을 추가할 때 관련된 모든 파일이 한눈에 보여서 유지보수에 좋을거 같았다.
관련 내용을 찾아보면서 의문점이 드는 부분이 있었다.
✅ 도메인형 구조를 쓴다고 해서 레이어드 아키텍처를 버리는 건 아니다!
도메인형 구조를 쓰더라도, 코드의 흐름은 여전히 Controller → Service → Repository 순서(= 레이어드 아키텍처)를 따른다.
도메인형 구조는 "폴더/패키지를 도메인 중심으로 나눈 것"일 뿐, 레이어드 아키텍처(Controller → Service → Repository)의 흐름은 그대로 유지된다.
도메인형 구조는 "하나의 기능을 하나의 모듈처럼 관리" 하기 위해 사용하고 프로젝트가 커져도 각 도메인이 독립적으로 관리되어 유지보수가 쉬워진다. 또한, 하나의 도메인에 필요한 모든 파일이 모여 있기 때문에 변경이 생겨도 다른 레이어를 왔다갔다 할 필요 없이 한 폴더에서 작업할 수 있다. 개인적으로 가장 크게 느낀 장점은 확장성이 높고, 결합도가 낮다는 것이다.
✅ 도메인 중심 설계(DDD: Domain-Driven Design)란?
비즈니스 도메인(업무 영역)을 중심으로 소프트웨어를 설계하는 방법론이다.
여기서 "도메인"은 단순히 코드 구조가 아니라, 실제 비즈니스에서 사용하는 개념과 흐름을 의미하며, 특히 복잡한 시스템에서는 "사용자", "주문", "결제" 같은 도메인별로 모델을 명확하게 분리하고, 이 도메인끼리 경계를 유지하는 것이 매우 중요해진다.
도메인형구조는 도메인별로 폴더를 나눠 도메인 간 경계를 명확히 설정할 수 있다. 따라서 도메인형 구조를 사용하면 DDD 스타일에 가까운 개발이라 생각이 든다.
📝 마무리
패키지 구조에는 정답이 없다.
프로젝트의 규모, 팀 스타일, 협업 방식에 따라 유연하게 선택하는 것이 중요하다.
하지만 한 가지 분명한 것은, 패키지 구조를 정했다면 반드시 일관성을 유지해야 한다는 점이다!
'개발 > JAVA' 카테고리의 다른 글
[MacOS] Homebrew로 JDK 설치하기 (1) | 2025.04.14 |
---|---|
[macOS] JDK 17 설치 & JAVA_HOME 환경변수 설정 (0) | 2022.02.07 |