지난 편에서 도메인 모델의 정의와 좋은 모델의 기준을 살펴봤어요. 이번 편에서는 도메인 로직이 시스템 안에서 실제로 어디에 위치해 있는지를 다뤄볼게요. 도메인 주도 설계의 계층 구조(Layered Architecture)가 무엇이고, 각 계층의 역할과 상호작용 원칙, 그리고 실제 흐름 예시까지 알아볼 거예요.
팀이 도메인 모델을 다루기 시작하면, 이런 질문이 곧바로 떠오를 거에요.
“이 모든 도메인 로직이 시스템에서 어떻게 구성되고 어디에 위치하게 되는거지?”
여기서 도메인 주도 설계의 계층 구조가 중요해져요. 계층 구조는 도메인이 시간이 지나도 이해 가능하도록 책임을 분리하는 방법이에요.
제품이 불안정하다고 느껴질 때, 도메인 규칙이 한곳에 모여 있지 않고 여러 계층에 흩어져 있는 경우가 많아요. 계층화의 핵심 아이디어는 관심사의 분리(Separation of Concerns)예요. 모든 것을 뒤섞는 대신, 팀이 시스템을 각각 명확한 역할과 서로 다른 질문에 답하는 계층으로 나누는 거죠.
각 계층이 답하는 질문은 다음과 같아요.
| 계층 | 답하는 핵심 질문 |
|---|---|
| 프레젠테이션(Presentation) | 사용자가 시스템과 어떻게 상호작용하는가? |
| 애플리케이션(Application) | 지금 어떤 유스케이스가 실행되고 있는가? |
| 도메인(Domain) | 비즈니스 규칙과 개념이 무엇인가? |
| 인프라스트럭처(Infrastructure) | 이것이 기술적으로 어떻게 지원되는가? |
각 계층의 관심사가 한 곳에 섞이면 문제가 발생해요. 작은 UI 변경이 비즈니스 규칙을 깨뜨리거나, 기술적 편의가 제품 행동으로 스며들어 경험을 망쳐요.
계층 구조는 병원의 역할 분담과 같아요. 접수처(프레젠테이션)는 환자와 소통하고, 간호사(애플리케이션)는 진료 흐름을 조율하고, 의사(도메인)는 진단과 치료 결정을 내리고, 검사실과 약국(인프라스트럭처)은 기술적 지원을 해요. 접수처 직원이 진단을 내리거나, 검사실이 치료 방침을 정하면 안 되듯, 각 계층도 자기 역할에 집중해야 시스템이 안정적이에요.
1. 프레젠테이션 계층: UX 가드레일
프레젠테이션 계층은 사용자나 외부 시스템이 제품과 처음 만나는 지점이에요. 화면, API, 관리자 도구, 파트너 인터페이스가 여기에 포함되죠.
중요한 건 여기에 무엇이 나타나는지가 아니라, 이 계층이 어떤 역할을 하는지예요.
프레젠테이션 계층은 다음과 같은 책임을 담당해요.
- 현재 시스템 상태를 사용자가 이해할 수 있는 방식으로 표시한다
- 사용자 입력과 신호를 수집한다
- 그 상호작용을 애플리케이션 계층이 처리할 수 있는 요청으로 변환한다
프로덕트 관리 관점에서 이 계층은 사용자 경험 흐름을 설계하고, UX 트레이드오프를 만들고, 언어·행동 유도(Affordance)·제약을 사용자에게 전달하는 곳이에요.
핵심 비즈니스 규칙을 프레젠테이션 계층에서 강제해서는 안 돼요.
예를 들어, 일정 관리 제품에서 “예약” 버튼을 비활성화하는 건 UX를 통해 사용자 행동을 안내하는 거예요. 하지만 예약이 겹침 규칙을 위반하는지 판단하는 건 UI, API, 통합 경로와 관계없이 유지되어야 하는 ‘도메인’ 계층의 관심사죠.
비즈니스 로직이 프레젠테이션 계층에 살게 되면, 같은 규칙을 여러 곳에서 다시 구현하게 되고, 경계 지점에서 일관되지 않은 행동이 생겨요.
프레젠테이션 계층을 비유하면, 레스토랑의 홀 서비스와 같아요. 웨이터가 “이 메뉴는 현재 재료가 없어서 주문이 어렵습니다”라고 안내할 수는 있지만(UX 가드레일), 실제로 “이 재료 조합은 알레르기 위험이 있어서 제공할 수 없다”는 판단은 주방(도메인)이 내려야 해요. 웨이터가 독자적으로 음식 안전 규칙을 판단하면 주방과 홀에서 다른 기준이 적용되겠죠.
2. 애플리케이션 계층: 작업 조율
애플리케이션 계층은 사용자 상호작용과 도메인 로직 사이에 위치해요. 비즈니스 규칙을 정의하지 않지만, 일이 어떻게 진행되는지를 조율하죠.
프레젠테이션 계층에서 요청이 들어오면, 애플리케이션 계층은 다음을 결정해요.
- 어떤 도메인 연산을 호출할지
- 어떤 순서로 할지
- 어떤 트랜잭션 경계 안에서 할지
이런 의미에서 이 계층은 이런 질문을 하는 거예요.
- “사용자가 회의실을 예약하면 실제로 무슨 일이 일어나는가?”
- “이 플로우가 어떤 도메인 개념을 건드리는가?”
- “이 단계들이 어떻게 맞물리는가?”
도메인 주도 설계의 핵심 원칙 중 하나는 애플리케이션 계층을 얇게 유지하는 거예요. 얇다는 건 중요하지 않다는 뜻이 아니에요. 이 계층이 비즈니스 규칙이나 오래 지속되는 상태를 소유하지 않고, 조율 역할(Orchestration)에 집중한다는 뜻이에요.
애플리케이션 서비스는 사용 흐름의 기술적 대응물이에요. 예약 생성, 예약 취소, 예약 일정 변경 같은 액션이 보통 도메인 행동을 조율하는 애플리케이션 수준 유스 케이스(Use Case)에 매핑되죠.
비즈니스 규칙이 이 계층으로 스며들기 시작하면 문제가 생겨요. 같은 로직이 여러 플로우에 중복되고, 비슷한 액션이 서로 다르게 동작하기 시작하죠.
애플리케이션 계층은 응급실 접수 간호사와 같아요. 환자가 들어오면 간호사는 “접수 → 활력징후 측정 → 담당 의사 배정” 순서를 조율해요. 하지만 “이 혈압 수치가 위험한가”, “어떤 처치가 필요한가”를 판단하는 건 의사(도메인)의 역할이죠. 간호사가 그 판단까지 직접 내리기 시작하면, 책임 경계가 무너지고 환자마다 다른 기준이 적용되기 시작해요.
3. 도메인 계층: 제품을 작동하게 하는 비즈니스 규칙
도메인 계층은 제품의 핵심 로직이 사는 곳이에요. 엔티티(Entity), 값 객체(Value Object), 도메인 서비스(Domain Service), 불변 조건(Invariant)이 모여서 비즈니스가 실제로 어떻게 작동하는지를 표현하죠.
다음과 같은 것들이죠.
- 제품이 진짜로 무엇을 허용하고 금지하는지
- 시간이 지나도 일관되게 유지되어야 하는 것이 무엇인지
- 왜 특정 변경이 불균형적으로 비용이 큰지
이 계층이 특히 중요한 이유는 비즈니스가 제대로 작동하기 위한 가정을 내재화하기 때문이에요.
“예약은 시작 후 수정할 수 없다”, “퍼실리테이터는 겹치는 세션을 진행할 수 없다”, “라이선스는 개인이 아닌 워크스페이스에 속한다” 같은 규칙은 개발을 위한 구현 세부 사항이 아니에요. 비즈니스가 운영되는 방식에 대한 선언이죠.
프로덕트 관리 측면에서 도메인 계층이 가장 중요한 이유가 바로 다음 때문이예요.
- 초기 명확화가 후속 재작업을 줄여요
- 불변 조건을 이해하면 로드맵 순서를 잡는 데 도움이 돼요
- 명확한 경계가 의도치 않은 범위 확장을 방지해요
도메인 계층은 시스템의 심장이에요.
도메인 계층을 비유하면, 국가의 헌법과 같아요. 일반 법률(다른 계층)은 상황에 따라 바뀔 수 있지만, 헌법(도메인 규칙)은 모든 법률의 기초가 되죠. 헌법을 바꾸는 건 가능하지만, 그 영향이 크기 때문에 신중하고 의도적으로 해야 해요. 도메인 계층의 규칙도 마찬가지로, 바꿀 수는 있지만 그 파급 효과를 이해하고 바꿔야 해요.
4. 인프라스트럭처 계층: 작동할 수 있는 시스템의 기반
인프라스트럭처 계층은 시스템을 지원하지만, 의미를 정의하지는 않아요.
인프라스트럭처 계층에는 데이터베이스, 외부 API, 메시징 시스템, 파일 저장소, 서드파티 서비스 등이 포함돼요. 이 요소들은 제품을 실행할 수 있게 하되, 비즈니스가 어떻게 작동하는지를 결정해서는 안 돼요.
프로덕트 관리에서 인프라스트럭처 논의는 보통 성능 제약, 비용 트레이드오프, 안정성·확장성 우려로 나타나요.
도메인 주도 설계에서는 도메인이 인프라스트럭처 세부 사항에 의존해서는 안 돼요. 이상적으로는 데이터가 어떤 데이터베이스에 저장되든, 알림이 어떤 서비스를 통해 보내지든 도메인에는 상관이 없어야 하죠.
이 분리가 다음과 것들을 쉽게 만들어요.
- 핵심 로직을 재작성하지 않고도 제품을 진화시킬 수 있다
- 제약이 바뀔 때 벤더나 기술을 교체할 수 있다
- 비즈니스 규칙을 왜곡하지 않고 시스템을 확장할 수 있다
인프라스트럭처 계층을 비유하면, 극장의 무대 뒤 스태프와 같아요. 조명, 음향, 무대 장치를 담당하는 스태프가 바뀌어도 연극의 대본(도메인)과 줄거리는 바뀌지 않죠. LED 조명에서 할로겐 조명으로 바꾸거나, 음향 시스템을 업그레이드해도 관객이 보는 이야기는 같아야 해요.
5. 계층 상호작용 원칙: 계층화가 변경을 격리하는 방법
┌──────────────────────────┐
│ 프레젠테이션 계층 │◀─ UI, API, 컨트롤러
└─────────────┬────────────┘
│ 의존
▼
┌──────────────────────────┐
│ 애플리케이션 계층 │◀─ 유스케이스, 오케스트레이션
└─────────────┬────────────┘
│ 의존
▼
┌──────────────────────────┐
│ 도메인 계층 │◀─ 비즈니스 규칙, 불변 조건
└─────────────┬────────────┘
│ 지원
┌──────────────────────────┐
│ 인프라스트럭처 계층 │◀─ DB, 메시징, 외부 API
└──────────────────────────┘
계층 구조에서 가장 중요한 규칙은 의존성 방향이에요.
팀은 의도적으로 의존성을 제약해서, 바깥 계층이 안쪽 계층에 의존하게 하고, 반대는 안 되게 해요. 이 제약이 변경의 영향이 퍼질 수 있는 범위를 제한하죠. 의존성이 한 방향으로 흐르면, 한 곳에서의 변경이 제품의 핵심을 조용히 바꿀 수 없거든요.
구체적으로 다음과 뜻이에요.
- 프레젠테이션이 애플리케이션에 의존한다 → UI나 API 변경이 액션을 트리거하는 방식에 영향을 줄 수 있지만, 시스템의 근본적인 규칙이나 기반에는 영향을 주지 않는다
- 애플리케이션이 도메인에 의존한다 → 사용자 플로우가 비즈니스 규칙을 재작성하지 않고 바뀔 수 있다
- 인프라스트럭처가 모두를 지원하지만 위로 누출되어서는 안 된다 → 데이터베이스나 벤더 변경이 제품 행동을 재정의해서는 안 된다
팀이 이 방향을 위반하면, 외부 계층에서 이상한 현상이 일어나기 시작해요. UI 전용 체커가 비즈니스 규칙처럼 작동하기 시작하거나, 데이터베이스 스키마나 쿼리 패턴이 제품이 할 수 있는 것과 없는 것을 지시하기 시작하죠. 시간이 지나면 “진짜” 규칙을 찾기 어려워져요. 여러 계층에 퍼져있으니까요.
그렇기 때문에 도메인 주도 설계는 구조가 아니라 의도를 전달해야 한다는 것을 의미해요
6. 예시 흐름: “회의실 예약” 액션이 계층을 통과하는 과정
모든 것을 연결해서 간단한 흐름을 볼게요. “회의실 예약” 액션이 계층을 통과하는 전형적인 모습이에요.
사용자가 "예약" 클릭
│
▼
┌──────────────────────────────┐
│ 프레젠테이션 계층 │
│ - 폼 입력 수집 │
│ - 형식 검증 (필수 값 확인) │
│ - 의도 표현: │
│ "이 회의실을 예약하겠다" │
└───────────────┬──────────────┘
│
▼
┌──────────────────────────────┐
│ 애플리케이션 계층 │
│ - CreateBooking 트리거 │
│ - 실행 순서 정의 │
│ - 트랜잭션 열기 │
└───────────────┬──────────────┘
│
▼
┌──────────────────────────────┐
│ 도메인 계층 │
│ - 예약 불변 조건 강제 │
│ - TimeSlot 규칙 적용 │
│ - 충돌 거부 │
│ - 예약 유효성 결정 │
└───────────────┬──────────────┘
│
┌──────────────────────────────┐
│ 인프라스트럭처 계층 │
│ - 예약 영속화 │
│ - 알림 전송 │
│ - 외부 시스템 통합 │
└──────────────────────────────┘
여기서 중요한 건 순서 자체가 아니라, 결정이 어디에서 이루어지는가예요.
- 초기 계층은 의도를 표현하고
- 도메인 계층은 비즈니스 규칙에 기반해 진실을 결정하고
- 인프라스트럭처는 결과를 실행해요
같은 흐름이 웹 UI에서 오든, 모바일 앱에서 오든, API 통합에서 오든 적용돼요. 진입 지점은 바뀌지만, 핵심 의사결정은 바뀌지 않아요.
다음 편에서는 DDD의 기본 구성 요소(Building Blocks)을 살펴볼게요. 엔티티(Entity)와 값 객체(Value Object)의 차이, 그리고 이 구분이 제품 결정에 어떤 영향을 미치는지를 알아볼 거예요.
도메인 주도 설계 시리즈