[Chapter 01] DDD의 Bounded Context

[JoisFe]

[Chapter 01] DDD의 Bounded Context

MSA는 서비스를 어떤 기준으로 나누는지가 어려운 문제 입니다.
책에서 보면 서비스를 얼마나 작게 나누어야 하는지 모호하기 때문에 전체 서비스를 마이크로서비스 단위로 구분하는 것이 어렵다고 하였습니다.
DDD의 개념 중 하나인 Bounded Context를 이해한다면 위의 문제를 해결하는데 도움을 준다고 하나, 해당 책에서는 해당 개념에 대한 설명이 부족한데, 아시는 분 이 있다면 좀 더 구체적으로 설명해주시면 감사하겠습니다. (cc. @corock )

[ahngilwoong]

제가 간략하게 검색을 해본 결과 서로 다른 서비스 간에 데이터 모델이나 도메인 모델을 공유하지 않는 것이 경계를 정하는 큰 고려사항이라고 합니다..

[corock]

저도 진행 중인 프로젝트에 DDD 도입을 준비하고 있고, 공부도 필요한 상황이라 정리하면서 댓글로 공유해 드립니다.

먼저 바운디드 컨텍스트(bounded context)를 잘 이해하려면 DDD 에서 말하는 컨텍스트(context)부터 잘 정의해야 할 것 같은데요.
컨텍스트를 잘 정리한 문장이 있어 소개하고자 합니다.

컨텍스트란, 어떤 것을 이해하고 해석하는 데 있어 그것이 속한 상황이나 배경, 관련된 다른 사항이 함께 고려되어야 하는 것을 지칭한다.

소프트웨어 개발에서 컨텍스트는 소프트웨어 시스템 일부로서 비즈니스 문제 영역을 나타낸다.
예를 들어, 은행 시스템에서 대출 신청, 계좌 개설, 이체 등 각각의 기능들은 서로 다른 컨텍스트를 가지고 있다.

참고로 도메인과 컨텍스트의 차이를 설명하면 도메인은 특정한 비즈니스 분야를 의미한다. (e.g. 은행, 항공, 호텔, ...)
이와 달리 컨텍스트는 도메인 안에서 특정한 비즈니스 문제 영역을 의미한다. (e.g. 은행 도메인의 대출 신청, 계좌 개설, ...)

이런 컨텍스트의 개념을 기반으로, 바운디드 컨텍스트(bounded context) 용어가 도메인 주도 설계에서 처음 소개되는데요.
바운디드 컨텍스트의 개념은 다음과 같습니다.

바운디드 컨텍스트는 큰 시스템을 여러 개의 작은 컨텍스트로 나누어
각 컨텍스트 내에서 특정한 비즈니스 규칙과 데이터 모델이 적용되는 것을 의미한다.

도메인 주도 설계를 좋아하는 분이 생각나네요...
전설적인 농구 선수 코드 네임을 가진 그 분의 블로그 게시글에서 참고한 이미지를 함께 보면 이해에 도움이 될 것 같습니다.

서브도메인과 바운디드 컨텍스트의 활용	핵심 도메인에 집중하기