Layered Application Boundary
원문은 View·Controller·Service·Domain의 책임을 나누는 MVC + Service 패턴을 제시하고, Service 도입 장점으로 Controller 단순화, Service 단독 테스트, 다른 Controller에서의 재사용을 든다.[1] 이 page는 레이어드 구조를 호출 순서 자체보다 각 책임이 어느 경계에 남아야 하는지를 정하는 규율로 보고, 이 분리로 사용자 인터페이스와 핵심 규칙이 서로의 변경을 덜 끌고 간다고 해석한다.
책임 배치
| 레이어 | 맡는 일 | 경계 밖으로 밀어낼 일 |
|---|---|---|
| View | 사용자 입출력 | 비즈니스 규칙·도메인 검증 |
| Controller | 흐름 조율과 오류 처리 진입점 | 도메인 계산 직접 수행 |
| Service | use case 조합 | UI 코드 |
| Domain | 핵심 규칙과 불변식 | 외부 I/O 의존 |
이 책임표는 원문이 제시한 레이어별 역할과 금지 사항을 재구성한 것이다.[1:1]
처리와 예외의 흐름
flowchart LR
V[View: 입력·출력] --> C[Controller: 흐름]
C --> S[Service: 조합]
S --> D[Domain: 규칙·불변식]
D -->|domain exception| C
C -->|오류 표시·재입력 유도| V- 문자열을 도메인 타입으로 바꾸는 파싱은 View 또는 Parser 경계에서 먼저 수행하고, 그 결과에 대해 도메인 규칙을 검증한다.[1:2]
- Domain은 규칙 위반을 예외로 표현하고, Controller는 사용자 경험에 맞게 이를 잡아 오류 표시나 재입력 흐름을 결정한다. 원문은 Service가 일반적으로 예외를 직접 catch하지 않는 배치를 예시로 든다.[1:3]
- Service를 두면 Controller가 간결해지고, 같은 use case를 다른 Controller에서 재사용하거나 단독 테스트하기 쉬워진다.[1:4]
경계가 무너지는 신호
- Controller에 파싱, 계산, 상태 변경이 한꺼번에 쌓인다.
- Domain이 화면 출력이나 입력 루프를 안다.
- Service가 단순 전달만 하거나, 반대로 도메인 규칙 전체를 흡수한다.
관련
- Console MVC Design: 콘솔 환경에서 이 경계를 적용하는 구체적 패턴이다.
- Domain Model Design: Domain과 Service를 무엇으로 나눌지 정하는 모델링 관점이다.
- Custom Exception Design: Domain의 실패를 Controller까지 전달하는 오류 표현 방식이다.