Bounded Context의 크기, Microservice의 크기

..

 

 

DDD를 사용한 도메인 모델의 주요 구성 요소인 모듈, 애그리게잇, 이벤트, 서비스는 하나의 바운디드 컨텍스트 안에 어느 정도의 수가 포함돼야 할까?
(이는 Microservice의 크기가 어느정도여야 하는가? 에 대한 물음과 동일하다)

이는 “줄 하나의 길이는 얼마나 되나요?”라고 묻는 것과 다를 바가 없다. 
바운디드 컨텍스트는 완전한 유비쿼터스 언어를 표현하기 위해 필요한 크기만큼 커야 한다.

(덩그러니 줄 하나만 두고 이게 긴가요 짧은가요 라고 묻는것과 같다.
어떤 Context에서 사용되는지를 알아야 답할수 있다
예를들면 매듭을 묶기에는 이정도면 적당할 수 있지만 큰 배를 묶기에는 턱없이 부족할 것이다

마찬가지로 테이블 10개, 기능 5개 정도의 서비스가 적당합니까라고 묻는것과 마찬가지다
10개 테이블끼리 5개의 기능끼리 응집도가 높다면 문제가 없겠지만
3개 테이블 7개 테이블간의 연관관계가 전혀 없는것을 하나의 서비스로 묶어두었다면 그 크기가 아무리 작아도 부적절하고 연관관계가가 높다면 응집도가 높다면 100개라도 아무리 크더라도 문제가 되지 않을것이다)

진정한 핵심 도메인의 일부가 아닌 외부 개념은 제외돼야 한다. 
만약 어떤 개념이 여러분의 유비쿼터스 언어 안에 들어있지 않다면, 
애초에 여러분의 모델에 들어오지 말아야 한다. 
만약 한 개 이상의 외부 개념이 여전히 비집고 들어오려 한다면 없애버리자. 
이는 아마 다른 지원 혹은 범용 서브도메인에 속하거나, 아예 어떤 모델 안에도 속하지 못한다.

DDD 원칙은 우리가 무엇을 넣고 빼야 할지 진지하게 생각하도록 해준다는 점이다. 
우리는 바운디드 컨텍스트를 사용하거나 컨텍스트 맵과 같은 도구를 사용해 
무엇이 진정 핵심 도메인에 속하는지 분석할 때 활용할 수 있다.

잘못된 크기의 바운디드 컨텍스트를 만들게 되는 이유는 무엇일까? 
우리는 실수로 유비쿼터스 언어가 아니라 아키텍처적 영향을 기준으로 삼았을 수 있다. 
어쩌면 플랫폼, 프레임워크, 컴포넌트, 또는 그 밖의 인프라스트럭처가 컴포넌트를 패키징하고 배포하는 데 사용되는 방식이 우리가 바운디드 컨텍스트를 바라보는 방향에 영향을 줘서, 
언어적 경계 대신 기술적 경계를 긋도록 했을 수도 있다.

또 다른 함정은 가용한 개발자 리소스로 작업을 분배하기 위해 바운디드 컨텍스트를 나누는 문제다. 
기술 리더와 프로젝트 관리자는 개발자가 더 작은 분량의 작업을 관리하는 일이 더 쉬울 것이라고 생각할 수 있다. 
그런 경우도 있을 수는 있지만, 작업 분배를 위해 경계를 강화하는 것은 컨텍스트 모델링의 언어적 동기 측면에선 잘못된 선택이다. 사실, 기술적 리소스의 관리를 위해 허위 경계를 부여할 필요가 없다.

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

 

 

..