0. 도메인 모델과 경계
DDD를 할 때 어려웠던 점이 있었다.
처음 도메인 모델을 만들 때 도메인을 완벽하게 표현하는 단일 모델을 만드는 시도를 하였었다. 하지만, 한 도메인은 다시 여러 하위 도메인으로 구분되기 때문에 한 개의 모델로 여러 하위 도메인을 모두 표현하려고 시도하면 오히려 모든 하위 도메인에 맞지 않는 모델을 만들게 된다.
예를 들어 상품이라는 모델을 생각해 보자. 카탈로그에서 상품, 재고 관리에서 상품, 주문에서 상품, 배송에서 상품은 이름만 같지 실제로 의미하는 것은 다르다. 카탈로그에서의 상품은 상품 이미지, 상품명, 상품 가격, 옵션 목록, 상세 설명과 같은 상품 정보가 위주라면, 재고 관리에서는 실존하는 개별 객체를 추적하기 위한 목적으로 상품이 사용한다. 즉 카탈로그에서는 물리적으로 한 개인 상품이 재고 관리에서는 여러 개 존재할 수 있다.
시스템을 사용하는 사람을 회원 도메인에서는 회원이라고 부르지만, 주문 도메인에서는 주문자라고 부르고, 배송 도메인에서는 보내는 사람이라고 부르기도 한다.
--> 한 개의 모델로 모든 하위 도메인을 표현하려는 시도는 올바른 방법이 아니며 표현할 수도 없다.
하위 도메인마다 사용하는 용어가 다르기 때문에 올바른 도메인 모델을 개발하려면 하위 도메인마다 모델을 만들어야 한다.
각 모델은 명시적으로 구분되는 경계(특정한 컨텍스트)를 가져서 섞이지 않도록 해야 한다.
모델은 특정한 컨텍스트(문맥)하에서 완전한 의미를 갖는다. 같은 제품이라도 카탈로그 컨텍스트와 재고 컨텍스트에서는 의미가 서로 다르다. 이렇게 구분되는 경계를 갖는 컨텍스트를 DDD에서는 Bounded Context라고 부른다.
1. Bounded Context
바운디드 컨텍스트는 모델의 경계를 결정하며 한 개의 Bounded Context는 논리적으로 한 개의 모델을 갖는다.
카탈로그 컨텍스트와 재고 컨텍스트는 서로 다른 용어를 사용하므로 이 용어를 기준으로 컨텍스트를 분리할 수 있다. 또한 Bounded Context는 실제로 사용자에게 기능을 제공하는 물리적인 시스템으로 도메인 모델은 이 바운디드 컨텍스트 안에서 도메인을 구현한다.
이상적으로 하위 도메인과 Bounded Context가 일대일 관계를 가지면 좋겠지만 현실은 그렇지 않을 때가 많다.
여러 하위 도메인을 하나의 Bounded Context에서 개발할 때의 주의할 점은 하위 도메인의 모델이 섞이지 않도록 하는 것이다.
한 프로젝트에 각 하위 도메인의 모델이 위치하면 아무래도 전체 하위 도메인을 위한 단일 모델을 만들고 싶은 유혹에 빠지기 쉽다. 이런 유혹에 걸려들면 결과적으로 도메인 모델이 개별 하위 도메인을 제대로 반영하지 못해 하위 도메인별로 기능을 확장하기 어렵게 되고 이는 서비스의 경쟁력을 떨어뜨리게 된다.
내가 지금껏 이 부분을 간과하고 단일 모델을 만들어서 통합했다는 것을 꺠달았다.... 잘못된 방식이었다.
비록 한 개의 바운디드 컨텍스트가 여러 하위 도메인을 포함하더라도 하위 도메인마다 구분되는 패키지를 갖도록 구현해야 하며, 이렇게 함으로써 하위 도메인을 위한 모델이 서로 뒤섞이지 않고 하위 도메인마다 Bounded Context를 갖는 효과를 낼 수 있다.
바운디드 컨텍스트는 도메인 모델을 구분하는 경계가 되기 때문에 바운디드 컨텍스트는 구현하는 하위 도메인에 알맞은 모델을 포함한다.
같은 사용자라 하더라도로 주문 Bounded Context와 회원 Bounded Context가 갖는 모델이 달라진다. 회원의 Member는 에그리거트 루트이지만, 주문의 Orderer는 벨류가 된다.
--> Bounded Context는 각자 구현하는 하위 도메인에 맞는 모델을 갖는다.
깨달은 점
과거에 진행했던 방식들은 DDD를 흉내만 낼 뿐 제대로 도메인 모델을 분리해서 설계하지 못했다는 것을 꺠달았다. 지금이라도 확실히 알게 되어서 이번 프로젝트에는 제대로 설계를 해봐야 겠다라고 느꼈다.
