Sub Domain과 Bounded Context 예

 

 - Implementing Domain-Driven Design 도메인 주도 설계 구현, 반 버논 p101

 

 

전자상거래의 바운디드 컨텍스트 안에는 비록 분명하게 구분되진 않지만 여러 내재된 도메인 모델이 있다.
분리될 수 있었다면 좋았을 도메인 모델이 사실상 하나의 소프트웨어 모델로 뭉쳐 있으며, 
이는 매우 안타까운 일이다. 

이 소매업체가 직접 구축하지 않고 써드파티에게 이 바운디드 컨텍스트를 구매했다면 문제가 덜했겠지만, 
이 시스템을 누가 관리하든 제품 카탈로그, 주문, 송장, 배송 모델 등을 
하나의 큰 전자상거래로 엮음에 따라 복잡도가 높아지며 부정적인 결과를 초래했다. 

새로운 기능을 추가하기 위해 다양한 논리적 모델이 더욱 커져감에 따라, 
대립되는 관심사 때문에 진행에 방해를 받는다. 
이런 상황은 다른 논리적 모델(새로운 주요 기능 집합)이 추가돼야 할 때 특히 더 심해진다. 
소프트웨어의 관심이 분명하게 분리시키지 않기 때문에 당연하게 벌어지는 일이다.

많은 소프트웨어 개발자가 최대한 모든 것을 하나의 시스템으로 묶어 만드는 것이 현명하다고 생각하고 있기 때문에 특히 더 안타깝다.

전자상거 래는 모두가 알고 있고 모두가 참여하는 기초적인 부분이기 때문에 모두의 요구를 분명히 충족시킬 수 있다. 하지만 얼마나 많은 관심을 하나의 서브시스템 안에 쌓아갈 수 있는지를 떠나서, 발생할 수 있는 소비자의 요구를 모두 충족시킬 수는 없다는 데 허점이 있 다. 정말 절대로 충족시킬 수 없다. 모든 것이 서로 연결돼 다른 모든 것과 서로 의 존성을 갖기 때문에. 여러 서브도메인으로 나눌 수도 있는 소프트웨어 도메인 모델을 굳이 구분 짓지 않는다면 변화가 계속됨에 따라 훨씬 큰 부담을 지게 된다. 그러나 DDD의 전략적 설계 도구 중 하나를 사용함으로써, 서로 얽혀 있는 모델의 실제 기능을 논리적 측면에서 분리시켜 복잡도를 어느 정도 낮출 수 있다. 그림 2.1 에선 논리적 서브도메인 분리를 점선으로 표시했다. 이는 우리가 써드파티 모델을 어떻게든 리팩토링해서 명백하게 분리된 모델로 만들어야만 한다는 말은 아니며, 적어도 우리가 해당되는 특정 소매업체 비즈니스 운영에 적용할 최소한의 분리 모델이 무엇인지 나타낸 것이다. 뿐만 아니라 논리적 서브도메인과 물리적 바운 디드 컨텍스트 사이의 연결성도 함께 표시해서 통합의 측면을 나타냈다.

 - Implementing Domain-Driven Design 도메인 주도 설계 구현, 반 버논 p102~103

 

위에서 언급되는 안타깝고, 부정적인 결과를 초래하고, 더 심해지고, 벌어지는 일들은

Microservice가 아닌 커다란 통합 시스템인  Monolith에 대한 이야기기도 하다.