도메인 주도 설계 (Domain Driven Developement)
등장배경
| 기존의 개발 | 도메인 주도 개발 |
| 데이터에 종속 | 문제 영역을 개념적으로 표현 |
| 모델링과 개발 간의 불일치 발생 | 이해관계자(개발, 기획, 사용자 등) 이 공통적으로 의미를 이해할 수 있음 => 효과적인 모델링 |
도메인
- 소프트웨어로 해결하고자 하는 문제 영역
- 한 도메인은 다시 하위 도메인으로 나눌 수 있다.
도메인 모델
- 도메인(문제 영역)을 개념적으로 표현한 것
- 도메인 모델을 여러 이해 당사자가 이해할 수 있는 개념적 모델링 가능
- 하위 도메인으로 개념 구체화 가능 ex) 상품 주문 도메인 => 주문자, 주문상품, 배송 (하위 도메인)
- 클래스 다이어그램, 상태 다이어그램, 시퀀스 다이어그램 등의 방식으로 표현 가능
- 도메인은 고정적이지 않기 때문에, 도메인이 변경되면 이에 따라 도메인 용어 및 모델도 변경 반영되어야 한다.
DDD 핵심 목표
"High cohesion" , "Loosly coupling"으로 각각의 도메인은 서로 철저히 분리되고,
높은 응집력과 낮은 결합도로 변경과 확장에 용이한 설계를 얻게된다
DDD 아키텍쳐
Layered Architecture
Layered Architecture를 올바르게 구현하기 위한 두 가지 중요한 규칙이 있다.
1. 위의 계층에서 아래 계층에는 접근이 가능하지만 아래에서 위로는 불가능한 것을 기본으로 한다.
2. 한 계층의 관심사와 관련된 어떤 것도 다른 계층에 배치되어서는 안된다.
| 영역 | 설명 |
| 표현(Interface) | 사용자의 요청을 처리하고 사용자에게 정보를 보여준다. 여기서 사용자는 소프트웨어를 사용하는 사람뿐만 아니라 외부 시스템일 수도 있다. - Controller 영역 |
| 응용(Application) | 사용자가 요청한 기능을 실행한다. 업무 로직을 직접 구현하지 않으며 도메인 계층을 조합해서 기능을 실행한다. - Service, 트랜잭션 관리, DTO변환, 사용자 인증/인가, 파라미터 검증 |
| 도메인(Domain) | 시스템이 제공할 도메인 규치을 구현한다. - Entitiy, Value, Aggergate, repository, dmaoin Service |
| 인프라스트럭처(Infrastructure) | 데이터베이스나 메시징 시스템과 같은 외부 시스템과의 연동을 처리한다. |
Layerd Architecture의 장단점
장점
- 각 레이어를 loosely coupling 된 형태로 구축하면서, 각각 자신의 관심사에만 집중할 수 있다.
- 핵심 비즈니스 로직을 순수하게 유지함으로써 유지보수와 확장성 측면에서 이득을 얻을 수 있다.
- 각 레이어에 서로 다른 추상화 수준을 가진 상태와 행동을 위치시킴으로써 코드 재사용성을 높일 수 있다.
단점
- 서비스가 커질수록 복잡도가 증가하여 확장성이 떨어진다.
- 레이어로 분리된 관심사 외에 다른 관심사가 생길 경우 패키지 분리 및 코드 배치가 어렵다.
댓글