| 레이어 | 설명 | 입력 DTO (요청 방향 ↓) | 출력 DTO (응답 방향 ↑) |
|---|---|---|---|
| Client | HTTP 호출 | — | — |
| Presentation | 요청 수신, 응답 반환 | Request |
Response |
| Facade | 흐름 조율, 여러 Service 호출 | Criteria |
Result |
| Service | 비즈니스 규칙 실행 | Command |
Info |
| Domain | 순수 비즈니스 모델 | Domain 객체 | Domain 객체 |
| Infra | JPA / MyBatis, DB 접근 | Domain 객체 | Entity → Domain 변환 |
한 줄 요약: 각 레이어는 변하는 이유와 시점이 다르다. 같이 두면 같이 깨진다.
DTO 분리는 아키텍처 강제 수단이 아니라 변경 격리 수단이다. 각 경계의 DTO는 "그 레이어가 책임지는 관심사의 변경"을 다른 레이어로 전파되지 않게 막는다.
JPA @Entity를 Controller까지 그대로 올려서 Response로 쓰면:
internalMemo 등)가 실수로 외부에 노출됨@Transient, @JsonIgnore, @JsonProperty가 Entity에 쌓임| 경계 | 막아주는 것 |
|---|---|
Request / Response |
API 스펙(필드명·버전·노출 여부)이 내부로 전파되지 않음 |
Criteria / Result |
HTTP 파라미터 구조, 페이징 관심사가 Service에 영향 안 줌 |
Command / Info |
Service 내부 구조가 Facade·API 응답 형태에 종속되지 않음 |
Entity ↔ Domain |
DB 스키마 변경이 도메인 로직에 영향 안 줌 |
Domain 순수 유지 |
@Entity, @JsonProperty 같은 외부 관심사가 도메인에 붙지 않음 |