2장. 도메인, 서브도메인, 바운디드 컨텍스트 / IDDD (도메인 주도 설계 구현)

개요

---

# 참고

IMPLEMENTING DOMAIN DRIVEN DESIGN (도메인 주도 설계 구현) - 반 버논 지음

 

# 개요

DDD에 대한 기술서적을 읽고 DDD가 무엇인지 이해하고 어떻게 코드에 적용시킬 수 있는지 고민해 보려고 한다.

 

# 2장의 로드맵

• 도메인, 서브도메인, 바운디드 컨텍스트를 이해
• 왜 전략적 설계가 필수적인지?
• 여러 서브도메인으로 이뤄진 실용적인 도메인을 구현
• 바운디드 컨텍스트의 개념과 기술

 

---

2장. 도메인, 서브도메인, 바운디드 컨텍스트

2-1. 도메인이란?

넓은 의미에서 도메인이란 한 조직이 행하는 일과 그 조직 안에 세계를 일컫는다. 조금 더 자세하게 정의한다면 이해의 영역과 조직의 작업을 수행하는 방법이 그 조직의 도메인이다. 한 조직을 위해 소프트웨어를 개발한다면, 그 조직의 도메인 안에서 일하고 있는 것이다. 실무에서 도메인이란 여러 의미를 가질수 있다. 도메인은 비즈니스의 전체 도메인을 말할 수 있고, 한 가지 핵심 부분이나 다른 지원 분야일 수도 있다. 

 

일반적으로 비즈니스 도메인은 하나로 응집력 있게 모든 항목을 포함하는 모델을 만들어야겠다고 생각할 수도 있지만, DDD에서의 목표는 오히려 반대이다. 그 조직의 전체 도메인은 여러 서브도메인으로 이뤄져 있다. DDD에서 모델은 바운디드 컨텍스트 안에서 만들어진다. 또한 도메인 모델의 개발은 전체 비즈니스 도메인에서 단 하나의 특정 분야에 집중할 수 있는 한 방법이다. DDD에서는 전체 비즈니스 도메인을 고유의 한 영역으로 적극적으로 분리하는 것이 성공적인 모델을 만드는 데 도움이 된다. 따라서 모든 소프트웨어 도메인은 다수의 서브도메인이 있다.

 

 

---

 

2-2. 서브도메인과 바운디드 컨텍스트의 활용

 

# 여러 서브 도메인이 서로 의존하게 된다면?

OOO기업은 공고, 주문, 상품, 회원, 맞춤법 검사등 여러개의 서브 도메인으로 이뤄져 있다. 이 기업의 바운디드 컨텍스트 안에는 비록 분명하게 구분되진 않지만 여러 내재된 도메인 모델이 있다. 분리될 수 있었다면 좋았을 도메인 모델이 사실상 하나의 소프트웨어 모델로 뭉쳐 있다. 따라서 복잡도가 높아지며 부정적인 결과를 초래할 수 있다. 이러한 구조는 새로운 기능을 추가하기 위해 다양한 노리적 모델이 더욱 커져감에 따라, 대립되는 관심사 때문에 진행에 방해를 받는다. 이러한 이유는 소프트웨어의 관심이 분명하게 분리되지 않았기 때문이다.

 

즉, 정리하자면 서로 연결돼 다른 모든 것과 서로 의존성을 갖게 되며, 여러 서브도메인으로 나누지 않는다면 변화가 계속됨에 따라 큰 부담을 가질수 밖에 없다. 하지만 DDD의 전략적 설계를 사용한다면 논리적 측명에서 분리시켜 복잡도를 낮출수 있다.

 

 

# 서브 도메인이 분리되지 않는 예시

어떠한 업체는 하나의 물류 창고를 가지고 있다. 여러 제품을 보관하고 있지만 충분한 공간이 되지 않아 일정 수량만 저장을 할 수 있다. 하지만 해당 업체는 날마다 인기 있는 물품이 다르기 때문에 유연한 공급이 힘든 상태이다. 어느날 A제품이 100개 대량 주문이 들어왔지만 창고에는 20개 뿐이다. 하지만 창고를 A제품으로 채울수 없는 상황이다. 내일은 B제품이 인기 있을지, C제품이 인기 있을지 모르기 때문이다. 즉, 이 업체는 재고관리에 따른 문제의 범위와 한계를 알아보지 않았으며 최적화 방안을 고려하지 않았기 때문이다.

 

 

# 바운디드 컨텍스트와 서브 도메인

하나의 바운디드 컨텍스트당 하나의 서브도메인이 있는 것이 좋은 패턴은 아니다. 엄격한 기준으로 하나의 바운디드 컨텍스트를 만드는 것이 중요하다.

 

# 네이밍의 중요성

언어적으로 어떤 바운디드 컨텍스트가 더 잘된 설계인가? 즉, 어느쪽이 명확한 도메인별 용어를 포함하고 있는가?

어느 서비스에서 고객이라는 용어는 다수의 의미를 지닐수 있다.

• 카탈로그를 살필 때의 고객
• 주문을 할때의 고객

이 둘은 서로 다른 의미를 가진다. 카탈로그를 살필 때의 고객은 이전의 구매, 충성도, 가능한 제춤, 할인, 배송 옵션이라는 컨텍스트가 사용된다. 하지만 주문을 할 때의 고객은 배송지 주소, 청구지 주소, 금액, 지불 방법등이 있다. 따라서 하나의 서비스 안에서도 고객은 여러 의미를 가지게 된다. 만약 각 용어의 의미를 명시적으로 지정하여 도메인 개념에 이름을 붙였다면, 이는 깔금한 바운디드 컨텍스트가 아니다.

 

 

# 핵심 도메인에 집중하기 

핵심 돔메인은 그 조직의 성공에 가장 중요한 비즈니스 도메인의 한 부분이다. 전략적 측면에서 비즈니스는 핵심 도메인에서 탁월함을 보여줘야 한다. 비즈니스의 성공을 지속시키기 위해 가장 중요한 부분이며, 가장 높은 우선 순위가 부여되며, 대부분은 핵심 도메인에 초점이 맞춰져야 한다.

 

# 지원 서브 도메인과 범용 서브 도메인

비즈니스에서 필수적이기는 하나 핵심은 아닌 부분을 모델링할 경우, 이를 지원 서브 시스템이라고 한다. 비즈니스 측면에서 해당 지원 서브도메인에 어느 정도 특화됐기 때문에 이를 만든다. 반면 비즈니스적으로 특화된 부분은 찾을 수 없지만 전체 비즈니스 솔루션에 필요하다면 이를 범용 서브 도메인이라고 한다. 지원 서브 도메인이나 범용 서브도메인이라고 해서 중요하지 않다는 의미는 아니다. 비즈니스 성공을 위해 중요하지만, 비즈니스가 아닌 부분에서 탁월할 필요는 없다. 

 

---

 

2-3. 왜 전략적 설계는 필수인가?

http://redutan.github.io/2018/04/28/IDDD-chapter02

머리로는 알겠는데.. 말로 표현하기가 어렵다.. 

 

 

---

 

2-4. 바운디드 컨텍스트 이해하기

바운디드 컨텍스트는 그 안에 도메인 모델이 존재하는 명시적 경계이다. 도메인 모델은 소프트웨어 모델로서 유비쿼터스 언어를 표현한다. 모델의 개념 안에 그 속성, 오퍼레이션과 함께 특별한 의미를 가지고 있기 때문에 생성된다. 두 모델을 각자의 며시적인 경계로 둘러싸면, 각 컨텍스트 안의 각 개념이 나타내는 의미가 확실해진다. 따라서 바운디드 컨텍스트는 주로 언어적 경계를 이룬다.

 

---

 

2-5. 바운디드 컨텍스트 크기

DDD를 사용한 도메인 모델의 주요 구성 요소인 모듈, 애그리게잇, 이벤트, 서비스는 하나의 바운디드 컨텍스트 안에 어느 정도의 수가 포함돼야 할까? 진정한 핵심 도메인의 일부가 아닌 외부 개념은 제외돼야 한다. 바운디드 컨텍스트를 너무 엄격히 제한하면, 필수적임에도 빠져버린 컨텍스트 개념으로 인해 구멍이 생긴다. 비즈니스 문제점의 핵심을 담지 못하는 개념을 계속해서 모델 위에 쌓아간다면, 무엇이 필수적인지 관찰하고 이해할 수 없게 된다. 하나의 바운디드 컨텍스트로 자연스럽게 맞아떨어지는 개념을 담고 있는 핵심 도메인에 초점을 맞추자. 이렇게 하면 응집된 모델과 자연스럽게 연결되는 컴포넌트를 찾아낼 수 있다.