Layered Architecture
한 줄 정의
Layered Architecture는 애플리케이션을 표현, 비즈니스, 데이터 접근 같은 계층으로 나누고 각 계층의 책임과 의존 방향을 제한하는 구조다.
실무에서 왜 문제 되는가
- Controller에 비즈니스 로직이 쌓이면 API 변경과 정책 변경이 함께 흔들린다.
- Repository에 업무 규칙이 들어가면 데이터 접근과 도메인 판단이 섞인다.
- 계층을 나눴지만 의존 방향이 뒤섞이면 테스트와 변경 영향 분석이 어려워진다.
- 단순 CRUD에도 과도한 계층을 만들면 생산성이 떨어진다.
동작 원리
- Controller는 요청/응답 변환과 인증된 사용자 context 전달을 담당한다.
- Service는 유스케이스 흐름, 트랜잭션 경계, 도메인 규칙 조합을 담당한다.
- Domain은 상태와 규칙을 표현한다.
- Repository는 저장소 접근을 추상화한다.
- 의존성은 보통 바깥 계층에서 안쪽 계층으로 흐르게 제한한다.
실무 판단 기준
| 상황 | 판단 |
|---|---|
| API 형식 변경 | Controller/DTO 중심으로 영향이 제한되어야 한다 |
| 업무 규칙 변경 | Service/Domain 중심으로 수정되어야 한다 |
| 저장소 변경 | Repository 구현 변경으로 영향이 제한되어야 한다 |
| 계층 이동 고민 | 변경 이유가 같은 코드를 같은 계층에 둔다 |
자주 나는 실수
- 계층을 나눴지만 모든 로직을 Service에만 몰아넣는다.
- Entity를 응답으로 그대로 노출한다.
- Repository 메서드명에 업무 정책을 과도하게 담는다.
- 계층 수가 많을수록 좋은 설계라고 생각한다.
확인 방법
- 코드 리뷰: 각 계층 코드가 어떤 변경 이유로 바뀌는지 확인한다.
- 테스트: 핵심 업무 규칙을 웹/DB 없이 검증할 수 있는지 본다.
- 의존성: 하위 계층이 상위 계층 타입을 참조하지 않는지 확인한다.
핵심 요약
Layered Architecture의 목적은 계층 자체가 아니라 변경 이유를 분리하는 것이다.
Controller는 입출력 변환, Service는 유스케이스 흐름, Repository는 저장소 접근을 담당한다.
업무 규칙은 가능한 한 웹과 DB 세부사항에서 떨어져 있어야 한다.
단순한 기능에 과도한 계층을 추가하면 오히려 이해 비용이 커진다.
계층 설계는 변경 영향과 테스트 가능성으로 검증한다.
꼬리 질문
- 계층을 나누는 기준은 무엇인가?
- Service가 너무 커지는 이유는 무엇인가?
- 단순 CRUD에서도 항상 같은 계층 구조가 필요한가?