Strategic-Design

정의 Bounded Context는 특정 모델이 정의되고 적용되는 경계에 대한 기술이다. 보통 하나의 하위 시스템이거나 특정 팀의 작업 범위에 대응한다. Fowler는 이를 “DDD 전략적 설계의 중심 패턴"이라고 부른다. DDD가 큰 모델을 다루는 방식은 그것을 여러 Bounded Context로 나누고, 그 사이의 관계를 명시적으로 밝히는 것이다. 동작 원리 큰 프로젝트에는 항상 여러 모델이 존재한다 Evans가 제시하는 근거는 세 가지다. 두 하위 시스템이 서로 다른 사용자 집단을 대상으로 하고, 하는 일이 달라서 서로 다른 모델이 유용한 경우가 흔하다 독립적으로 일하는 팀들은 소통 부족으로 같은 문제를 다른 방식으로 해결한다 도구 자체가 달라서 코드를 공유할 수 없는 경우도 있다 여러 모델이 존재하는 것은 불가피하다. 문제는 서로 다른 모델에 기반한 코드가 합쳐질 때 생긴다. 소프트웨어에 버그가 생기고, 신뢰할 수 없게 되고, 이해하기 어려워진다. 팀원 간 소통도 혼란스러워진다. 어떤 컨텍스트에서 모델을 적용하면 안 되는지가 불분명해지기 때문이다. ...

정의 Ubiquitous Language(보편 언어)는 도메인 모델을 중심으로 구조화되어, 하나의 Bounded Context 안에서 팀 전원이 사용하는 언어다. 팀의 모든 활동을 소프트웨어와 연결하는 역할을 한다. Evans가 이 용어로 가리키는 것은 개발자와 사용자 사이에 공통되고 엄격한 언어를 구축하는 실천이다. 이 언어는 소프트웨어에서 사용하는 도메인 모델에 기반해야 한다. 소프트웨어는 모호함을 잘 처리하지 못하므로 언어가 엄격해야 하기 때문이다. 동작 원리 언어가 파편화되는 방식 하나의 Bounded Context 안에서도 언어는 여러 갈래로 쪼개진다. 모델이 기술 담당자를 위한 UML 다이어그램을 그리는 데만 쓰인다면, DDD의 핵심인 창의적 협업에 기여하지 못한다 도메인 전문가는 자기 업계 용어를 쓰고, 기술 담당자는 설계 관점에서 도메인을 논하기 위한 자기 언어를 쓴다 일상 대화의 용어가 코드에 박힌 용어와 단절된다. 코드야말로 소프트웨어 프로젝트의 가장 중요한 산출물인데도 그렇다 같은 사람도 말할 때와 쓸 때 다른 언어를 쓴다. 그래서 도메인을 가장 예리하게 표현한 말이 순간적인 형태로 등장했다가 코드에도 문서에도 남지 않고 사라진다 번역은 소통을 무디게 만들고 지식 정제를 빈혈 상태로 만든다. 그리고 이 방언들 중 어느 것도 공통 언어가 될 수 없다. 어느 것도 모든 요구를 충족시키지 못하기 때문이다. ...

개요 Bounded Context를 정의하는 것만으로는 부족하다. 전체를 보는 시야가 없으면 다음 문제가 남는다. 다른 모델의 컨텍스트가 여전히 모호하고 계속 변한다 다른 팀 사람들은 컨텍스트 경계를 잘 모르므로, 모르는 채로 경계를 흐리거나 연결을 복잡하게 만드는 변경을 한다 경계가 분명해도, 다른 컨텍스트와의 관계가 모델의 성격이나 변경 속도에 제약을 건다. 이 제약은 주로 비기술적 경로로 나타나기 때문에 그것이 영향을 주는 설계 결정과 연결짓기 어렵다 Context Map은 이 관계들을 명시적으로 그리는 작업이다. 그리는 방법 Evans의 처방은 다음과 같다. ...