DDD(Domain-Driven Design), 도메인 주도 설계란 무엇일까?
가장 먼저 도메인이란 무엇인지 알아보자.
도메인이란?
소프트웨어로 해결하고자 하는 문제 및 관심사
- 쇼핑몰을 구현한다고 하면, 쇼핑몰 자체가 가장 큰 문제 영역인 도메인이 된다.
그리고 쇼핑몰의 하위 도메인으로 '회원', '상품', '주문', '배송', '장바구니' 등등이 설정될 수 있다. - 이 도메인들은 사용자가 누구인지에 따라 달라질 수 있다.
도메인 모델이란?
도메인 모델은 도메인에 대한 지식을 단순하게 개념적으로 구조화한 형태이다.
일반적으로 UML 다이어그램과 같이 표현된 개념 모델을 도메인 모델이라고 한다. (꼭 다이어그램으로 표현될 필요는 없다)
아키텍처 상에서 도메인 모델은 마틴 파울러가 PEAA에서 언급한 것으로, 도메인 레이어를 객체지향적으로 구현하는 패턴을 가리키는 용어이다.(즉, 패턴의 일종이며 원래의 도메인 모델과는 약간 거리가 있다.
도메인 객체 모델이란?
도메인 모델에 대한 표현을 코드로 나타낸 것
'회원' 도메인을 Member 클래스로, '상품' 도메인을 Item 으로 나타낼 수 있다. 이러한 클래스들을 도메인 객체 모델이라고 할 수 있고, 도메인 객체 모델이 인스터화 된 것을 도메인 객체라고 한다.
도메인 주도 설계(Domain-Driven Design)
쇼핑몰에서 회원이 상품을 주문 하는 도메인이 있을 수 있고, 배송하는 도메인이 있을 수 있고, 회원가입을 담당하는 회원가입 도메인이 있을 수 있다.
각각의 도메인은 다른 도메인들과 상호작용하며 기능을 수행하게 된다. 이렇듯 비즈니스 도메인별로 나누어 설계하는것이 도메인 주도 설계(DDD)다.
DDD의 목표
높은 응집력과 낮은 결합도로 도메인은 서로 독립적인 구조를 가지며, 변경과 확장에 용이한 설계를 하는것을 목표로 한다.
높은 응집력과 낮은 결합도를 쉽게 설명하자면,
높은 응집력은 하나의 클래스에 하나의 책임이 잘 모여있는 것을 의미하며, 낮은 결합도는 각각의 클래스간에 의존성이 높지 않음을 의미한다.
DDD의 계층구조(Layered Architecture)
일반적으로 4개의 계층 구조로 나뉘어진다.
-
Presentation Layer(Controller)- 사용자 요청에 대해 해석하고 응답하는 일을 책임진다.
- 즉, 클라이언트에게 요청을 받고 응답을 반환하는 역할을 하는 모든 클래스가 해당된다.
-
Application Layer(Service)- 비즈니스 로직을 정의하고 도메인 계층과 infrastructure 계층을 연결해주는 역할을 한다.
- 많은 정보를 가지고 있지 않도록 하는 것이 좋다.
- 실질적인 데이터 상태 변화 처리는 도메인 계층에서 진행할 수 있도록 한다.
Application Layer에서는 다음과 같은 기능들을 포함한다.
- 트랜잭션 단위
- DTO 변환
- 엔티티 조회/저장
Entity를 찾고, 변경 내용 저장 기능을 호출한다. 구현은 Infrastructure Layer에서 구현한다. - 사용자 인증/인가
Presentation Layer에서 처리할 수 있는 url에 대한 인가 외에 다른 인가가 필요할 경우(DB와 대조 해야할 경우 등) - 파라미터 검증
Presentation Layer에서는 요청 방식에 따라 달라지는 '형식'에 대한 검증을 하고, Application Layer에서는 '논리' 오류를 검증한다.
-
Domain Layer(Model)- 비즈니스 규칙/정보에 대한 실질적인 도메인에 대한 정보를 가지고 있으며, 모든 책임을 지는 계층이다.
- Entity를 활용한 도메인 로직이 실행되고, 업무 상황을 반영하여 상태를 제어하는 역할에 집중한다.
-
Infrastructure Layer(Repository)- 외부 통신(DB, 메시징 시스템)을 담당하는 계층이다.
- 해당 계층에서 얻어온 정보를 Application Layer 또는 Domain Layer에 전달하는게 주 역할이다.
이와 같이 도메인을 분리하고, 이 도메인들을 위와 같은 Layer로 철저히 분리해서 만든 것이 DDD라고 할 수 있다.
아마 보면서 의아했던 부분이 있었을 것이다. Application Layer를 Service라고 적어두었는데, Domain Layer에 기술되어 있는 내용이 우리가 기존에 알고 있던 Service의 역할과 더 유사해 보인다.
이러한 편견은 Service에 대한 고정관념에서 비롯될 수 있다. Service는 무거운 동작을 포함하거나, 외부 호출만을 의미하는것이 아니라 오퍼레이션의 종류 중 하나일 뿐이다.
서비스는 언제 써야 하나? : 중요한 비즈니스 프로세스를 수행할 때, 어떤 컴포지션에서 다른 컴포지션으로 도메인 객체를 변경할 때, 하나 이상의 도메인 객체에서 필요로 하는 입력 값을 계산할 때 등
Application Service VS Domain Service
Service는 여러 계층에 존재할 수 있다. Application Service는 도메인 모델의 직접적인 클라이언트이며, DDD에서 Usecase들을 관리하는 것이 바로 이 Application Service이다.
어떤 행동이나 프로세스가 도메인에서 중요한 의미를 가져 도메인 모델이 적합하다면 Domain Service로 사용하고, 그렇지 않은 단순한 로직이라면 Application Service로 사용한다.
패키지 구조에 대한 예시가 궁금하다면 샘플 링크 를 참조 해보자.
