[DDD] BoundedContext 바운디드 컨텍스트

비즈니스에서는 여러 용어들이 존재합니다.

하지만 이러한 용어들은 용어는 같으나 다른 역할을 하는 경우,

그리고 같은 역할이지만 다른 용어로 불리는 경우가 있습니다.

예시를 들어봅시다.

 

판매 기능에서의 상품과 재고관리 기능에서의 상품이 있습니다. 

이 두가지는 같을까요? 

 

아마 판매 기능에서의 상품은 실재하는 물건이라기 보다는 어떤 무형적인 판매할 수 있는 카테고리일 것 입니다.

반면에, 재고관리 기능에서는 실제로 존재하는 물건이 몇개인지가 중요한 것이 됩니다.

 

이렇게, 같은 것으로 보임에도 비즈니스의 특성에 따라 완전히 다른것이 됩니다.

간단하게 말하면, 이런 것들을 명확히하여 설계에 반영하기 위하여 비즈니스의 경계를 분리한 것을 

 

BoundedContext 바운디드 컨텍스트 라고 합니다.

 

용어 자체는 매우 간단하고 쉬우나

설계에서 명확히 다른것 으로 구분이 되어야 하는 것을, 공통된 모델 혹은 모듈로 분리하여 생기는 문제를 방지하고

경계를 명확히하여 모듈의 응집도를 높여 변경에 대한 사이드 이펙트를 줄이는 도메인 주도 설계를 시작하기 위한 중요한 개념이라고 볼 수있습니다.

 

그렇다면 바운디드 컨텍스트는 어떻게 도출할 수 있을까요?

 

에릭 에반스의 도메인주도설계 에서는 설계를 전략적 설계와 전술적 설계 2가지로 나눕니다.

2가지를 상세히 기술하는건 포스팅의 목적에 맞지 않아 바운디드 컨텍스트를 도출하는 방법과 밀접한 전략적 설계만 다루어 보겠습니다.

---

Ubiquitous Language 유비쿼터스 언어

 

전략적 설계를 알기 전에 보편언어 라고 불리는 유비쿼터스 언어에 대해 이해가 필요합니다.

유비쿼터스 언어란, 비즈니스에서 실제로 사용할 혹은 사용하는 개념 용어들을 말합니다.

회사에서 업무를 하다보면, 똑같은 것에 대하여 팀에따라 혹은 각각의 개개인이 표현하는 용어가 달라 혼동이 온 경험이 있을겁니다.

프로젝트를 진행하기 전, 이러한 용어들을 프로젝트 조직 내에서 정리하여 보편적으로 사용하도록 정리하고 실제로 사용하는 용어를 유비쿼터스 언어라고 합니다.

 

전략적 설계

 

전략적 설계란 상세히 도메인의 세부사항을 도출해내는 기술적인 과정이 아닌, 도메인 전문가와 기술팀이 함께 유비쿼터스 언어를 통하여 서로의 지식을 공유하고 이를 개념과 경계를 식별하여 도메인과 바운디드 컨텍스트를 도출하는 과정을 말합니다.

 

위의 개념들은 협업을 통한 프로젝트의 순항을 위한 준비절차라고 볼 수 있겠습니다.

전략적 설계를 위해 보편적으로 두가지의 방법론을 제시합니다. 

 

첫번째는 이미 보편적으로 알려져있는 스크럼 기반의 Agile 방법론이고

두번째는 설계의 영역을 위한 Event Storming 이벤트 스토밍이 있습니다.

 

이벤트 스토밍의 경우는 저 보다는 직접 경험을 바탕으로 작성된 글이 좋을 것 같아 좋은 포스팅의 링크를 첨부하겠습니다.

https://engineering-skcc.github.io/microservice%20modeling/Event-Storming/