바운디드 컨텍스트로 솔루션 만들기

솔루션은 도메인의 필요한 정보만 캡처하면 됩니다.

 

따라서 우리는 "문제 공간"과 "해결 공간"을 구분해야 하며 두 가지 다른 것으로 취급되어야 합니다.

솔루션을 구축하기 위해 문제 도메인의 모델을 생성하고 관련 도메인 측면만 추출한 다음 그림과 같이 솔루션 공간에서 다시 생성합니다.

솔루션 공간에서 문제 공간의 도메인과 하위 도메인이 DDD 용어로 바운디드 컨텍스트라고 부르는 것에 매핑되어 있음을 볼 수 있습니다.

바운디드 컨텍스트는 구현에서 일종의 서브 시스템입니다. 각 바운디드 컨텍스트는 자체적으로 미니 도메인 모델입니다.

서브시스템보다 바운디드 컨텍스트라는 용어가 적합한 이유는, 시스템 간의 경계를 인식하고, 해당 경계 내에서의 컨텍스트를 인식하는게 중요하기 때문입니다.

 

왜 컨텍스트라는 용어를 사용하나요? 각 컨텍스트는 솔루션의 일부분의 전문 지식을 나타내기 때문입니다.

컨텍스트 내에서 우리는 공통 언어를 공유하며 디자인은 일관되고 통합되어 있습니다.

그러나 현실 세계에서와 마찬가지로 컨텍스트에서 벗어난 정보는 혼란스럽거나 사용할 수 없을 수 있습니다. (전문용어)

 

왜 바운디드(경계)라는 용어를 사용하나요?

현실 세계에서 도메인에는 모호한 경계가 있지만 소프트웨어 세계에서는

개별 하위 시스템 간의 결합을 줄여 독립적으로 발전할 수 있기를 원합니다. 즉 실제 세계의 교집합과 같은 부분을 없앱니다.

해당 교집합 부분을 API 기반 커뮤니케이션 등으로 변경할 수 있습니다.

 

또한 실제 세계의 도메인은 더 많은 도메인으로 쪼개지거나 합해질 수 있습니다.

 

도메인을 분할하더라도 각 바운디드 컨텍스트가 명확한 책임을 지는 것이 중요합니다.

모델을 구현할 때 제한된 컨텍스트가 일종의 소프트웨어 구성 요소와 정확히 일치하기 때문입니다.
구성 요소는 별도의 DLL, 독립 실행형 서비스 또는 단순한 네임스페이스로 구현될 수 있습니다.

지금은 세부 사항이 중요하지 않지만 파티션을 올바르게 나누는 것이 중요합니다.

컨텍스트를 올바르게 나누기

• 도메인 전문가의 말을 들어라.
  • 그들이 비슷한 용어를 사용하고 비슷한 문제를 다루면 같은 서브도메인에서 일할 가능성이 큽니다.
• 존재하는 팀, 부서에 집중하라
  • 조직 구조는 도메인과 서브도메인에 대한 강력한 힌트입니다.
• 바운디드 컨텍스트의 경계에 집중하라
  • 너무 크거나 모호한 경계를 피하세요
  • 좋은 울타리가 좋은 이웃을 만든다.
• 자율성을 위해 디자인하라 
  • 경계 컨텍스트를 분리하여 독립적이고, 자율적으로 만들어라
• 마찰 없는 비즈니스 워크플로를 위한 디자인.
  • 워크플로가 경계가 지정된 여러 컨텍스트와 상호 작용하고 이에 의해 자주 차단되거나 지연되는 경우 컨텍스트를 리팩토링하여 워크플로를 원활하게 만드는 것을 고려하십시오. 즉, 어떤 종류의 "순수한" 디자인보다 항상 비즈니스 및 고객 가치에 중점을 둡니다.
  • 항상 변화의 가능성을 염두에 두고 설계해야 합니다.

Creating Context Maps - 컨텍스트 매핑

이러한 컨텍스트를 정의한 후에는 디자인의 세부 사항에 얽매이지 않고

컨텍스트 간의 상호 작용(큰 그림)을 전달할 수 있는 방법이 필요합니다. DDD 용어로 이러한 다이어그램을 컨텍스트 맵이라고 합니다.

여행에 사용되는 노선도를 생각해 보십시오. 경로 지도는 모든 세부 사항을 표시하지 않습니다. 여행 계획을 세울 수 있도록 주요 경로에만 초점을 맞춥니다. 예를 들어, 다음은 항공사 노선도의 스케치입니다.

같은 방식으로 컨텍스트 맵은 다양한 경계 컨텍스트와 이들의 관계를 상위 수준에서 보여줍니다.

맵을 만들 때 배송 컨텍스트의 내부 구조는 고려하지 않고 Order-taking 컨텍스트에서 데이터를 수신한다는 점만 고려합니다.

두 컨텍스트는 교환하는 메시지의 공유 format에 동의해야 합니다.
일반적으로 업스트림 컨텍스트는 format에 더 많은 영향을 미치지만 때로는 다운스트림 컨텍스트가 유연하지 않습니다
(예: 다운스트림이 고치기 어려운 레거시 시스템 작업).
그리고 업스트림 컨텍스트는 이에 적응해야 하며, 그렇지 않으면 일종의 번역기 구성 요소가 중개자로서 필요합니다.

Focusing on the Most Important Bounded Contexts

일반적으로 일부 도메인은 다른 도메인보다 더 중요합니다.

 

코어 도메인은 비즈니스 이점을 제공하고 수익을 창출하는 핵심 영역입니다.

지원 도메인(supportive domains)은 필요할 수 있지만 핵심은 아닙니다.

일반 도메인(generic domains)은 비즈니스에 고유하지 않은 영역입니다.

 

예를 들어 Widgets Inc(예시 회사)의 경우 비즈니스 이점이 탁월한 고객 서비스이기 때문에 주문 접수 및 배송 도메인이 핵심일 수 있습니다.

청구 도메인은 지원 도메인(supportive domains)으로 간주되고

배송 도메인은 일반적인 도메인(generic domains.)으로 간주될 수 있으므로 안전하게 아웃소싱할 수 있습니다

 

가장 중요한 영역이 무엇인지에 대한 합의가 없는 경우가 있습니다.

각 부서는 자신의 도메인이 가장 중요하다고 생각할 수 있습니다.

그리고 때때로 핵심 도메인은 단순히 클라이언트가 작업하기를 원하는 모든 것입니다.

그러나 모든 경우에 우선 순위를 지정하고 모든 컨텍스트를 동시에 구현하려고 시도하지 않는 것이 중요합니다.

이는 종종 실패로 이어집니다.

코어 도메인 바운디드 컨텍스트에 초점을 맞춘 다음 거기에서 확장하십시오.