클린 아키텍처 + DDD의 설계 원칙
"이걸 왜 이렇게 쪼개야 하지? 그냥 Request → Entity로 바로 가면 안 되나?"
이런 의문을 가진 분들을 위해, 각 계층이 나뉘는 이유를 정리해봅니다.
🔍 1. 각 객체의 역할
| 타입 | 이름 예시 | 역할 | 소속 계층 |
|---|---|---|---|
| Request | CreateBannerRequest | 클라이언트 요청 바인딩, API 입력 검증 (@RequestBody) | Controller |
| Command | CreateBannerCommand | 유스케이스 실행에 필요한 비즈니스 데이터 | Application (UseCase) |
| Entity | BannerEntity 또는 Banner | DB 저장을 위한 영속 객체, 도메인 규칙 내포 | Domain / Infrastructure |
✅ 2. 왜 나눠야 할까?
2-1. 계층별 책임을 분리하기 위해
- API 로직과 도메인 로직을 분리함으로써 책임이 명확해지고, 변경이 서로에게 영향을 주지 않음
예:
CreateBannerRequest가 바뀌어도Entity는 영향 없음
2-2. 검증 위치를 구분하기 위해
- Request는
@Valid,@NotBlank등 API 요청 유효성 검사에 초점 - Command는 비즈니스 규칙을 통과한 "의도된 명령"만 전달
2-3. 도메인 모델을 보호하기 위해
- 외부에서 들어온 Request를 직접 Entity로 매핑하면 도메인 침범 위험 있음
- 중간 계층(Command)을 두어 도메인 불변성과 일관성을 보장
2-4. 재사용성과 확장성을 확보하기 위해
CreateBannerCommand는 API 외에도 Kafka 소비, 배치 작업 등 다양한 유입 경로에서 재사용 가능Entity는 저장 전용이므로 다른 계층에 노출하지 않아도 됨
2-5. 테스트 및 유지보수 편의성 향상
- 각 레이어 단위로 단위 테스트 가능 (Request → Controller, Command → UseCase, Entity → Repository)
- 역할이 분리되니 디버깅이 명확해짐
📦 3. 정리
| 기준 | 분리하지 않음 | 분리했을 때 |
|---|---|---|
| 변경 전파 위험 | 높음 | 낮음 |
| 단위 책임 | 뒤섞임 | 명확함 |
| 재사용성 | 낮음 | 높음 |
| 테스트 | 어렵고 모호함 | 계층별 용이함 |
✅ 4. 마무리
실무에서 DTO를 구분하는 건 단순한 클래스 나누기가 아니라, 계층 간 의존성을 끊고, 유지보수를 용이하게 하기 위한 핵심 설계 원칙입니다.
Spring 기반 MSA, DDD 구조라면 꼭 이 구조를 고려해보세요.
- ?