MVC 패턴으로 웹개발을 하다보니 오래전부터 레이어드 아키텍쳐에 익숙해져 있었다.
레이어드 아케텍쳐라 함은, controller > service > dto(repository) 구조인데 DDD 폴더 구조로 알게되어 신선한 충격을 받았었다.
그리고 DDD 폴더 구조가 Domain Driven Design 의 전부인지 알고 나는 DDD를 해봤다!!! 라고 생각했는데...

알면알수록 생각보다,, 딥하고 딥한 세계였구나..
그러치 간단한게 없지..
요즘 도메인 도메인 많이 말들 하지만 정확하게 알고자 공부를 시작하려고 한다.
나랑 같이 알아볼사람~~~
도메인이란?
소프트웨어로 해결하고자하는 문제영역
더 세세하게 말하자면 유사한 비즈니스의 집합이다.
더 개발로 들어가면 코드의 구조를 비즈니스에 맞춰감에 가깝다.
이 도메인이라는 개념을 개발에 적용하기 시작한 이유가 도메인에 대한 지식이 부족해서 설계 및 개발 과정에사 리소스가 많이 낭비되기 때문이라고 한다.
이런 백그라운드를 인지하고 나면 비즈니스에 대한 이해가 무조건 선행되어야함을 알 수 있다. 때문에 각 이해관계와 협업에 관한 얘기도 많이 나오는 것 같다.
도메인은 추상적이라 사람마다 정의하는 기준이 다를 수 있을 것 같다. 도메인 모델이란 특정 도메인을 개념적으로 표현한 것이다. 여기서 좀 더 각자가 생각하는 도메인이 구체화 되는것같다.
예를들어 [주문] 이라는 도메인에는 주문번호, 총금액, 주문 취소 같은 것들이 함께 따라올 것이다. 마인드 맵처럼 말이다.

좀더 객체 정보처럼 나타내면 아래와 같을 것이다. 위의 마인드맵 같은 단위를 좀더 세분화 하여 객체 정보로 나타낸 것으로 1:1 매칭되진 않을 것이다.

기준이 객체가 되었든, 상태 flow가 되었든 이 모델을 정의하고 나면 이해 관계자들과 소통하기가 원활할 것이다.
도메인 모델이란 도메인이 제공하는 기능과 주요 데이터 구성을 파악하는, 도메인을 이해하기 위한 모델인 것이다. 때문에 개발에서 바로 사용하기엔 어려움이 있다.
주의
도메인은 하위도메인을 가질 수 있는데, 각 도메인은 혼재되어 모델링 하면 안된다.
하나의 도메인모델은 하나의 도메인만 다루는게 훨씬 이해하기 편하다.
우리가 흔히아는 표현 > 응용 > 도메인(시스템이 제공할 도메인 규칙) > 인프라스트럭쳐 (db와 같은 외부시스템과 연동) 의 애플리케이션 아키텍쳐는 도메인을 이해하는데 필요한 개념적인 모델이다.
아키텍쳐 상의 도메인 계층을 객체 지향 기법으로 구현하는 패턴은 다음과 같다.
도메인 계층은 도메인의 핵심 규칙을 구현한다.
무슨말이냐면, 도메인 계층에 핵심 규칙이 위치한다는 뜻으로 객체지향을 더욱더 객체 지향으로 사용한다는 뜻과 같다고 생각된다.
예를 들어 아래와 같다.
public class Order {
private OrderState state; //주문 상태
private int totalAmount; //총액
// 결제
public void pay() {
if(state != OrderState.CREATED) { // 주문 상태가 생성이라면
throw new IllegalStateException("이미 결제 되었거나 취소된 주문 입니다")
}
this.state = OrderState.PAID; //그 외 경우 결제로 취급
}
}
말 그대로 기존에 우리가 작성했던 도메인에 핵심 규칙이 들어가 있는 셈이다.
그 도메인에 귀속적인 로직이라면 하나의 도메인에서 관리하는 것이다.
이를 통해서 규칙이 변경되거나 확장해야할때 해당 클래스만 변경하면 되기 때문에 조금더 객체 지향적인 코드가 되었다고 할 수 있겠다.
개념모델 / 구현 모델?
개념모델은 현실에서 다양한 이해 관계자들과 소통을 위한 문제를 분석한 결과물로 구현에 필요한 정보를 담고있지 않다.
구현모델 개념모델을 기반으로 점진적으로 발전해온 구현을 위한 모델이다.
둘은 다른 개념이 아니라 개념모델이 살을 붙이고 변형해 가며 결국 구현 모델이 된다.
도메인주도개발 시작하기 도서
도메인주도 설계 개념