DDD - Bounded Context를 정의해보자

MSA로의 마이그레이션 과정에서 느낀 경험과 이론으로 봤을때, 최대 단점은 역시 어려움이 꼽힌다고 생각한다. 

 

그러면 MSA 아키텍처가 왜 어려울까?

1. 도메인 분해를 위한 설계의 어려움

2. 마이크로서비스간의 통신(IPC)의 어려움

3. 분산 환경에서의 트랜잭션 관리의 어려움

 

지극히 주관적인 의견이지만 일부는 모두가 동의할 것이라 믿는다.. 나만 어려운게 아니길

 

 

 

그중에서 기존 모놀리식 아키텍처를 도메인별로 잘게 나누어 분해하는 과정이 시작부터 우리들의 발목을 잡게 된다. 

 

처음 접하는 사람들 입장에서 생각해보자.

 

 

그래 알겠어 각 서비스별로 쪼개서 만들면 되는거. 근데 무슨 기준으로 마이크로서비스를 나누는거지?

 

 

도메인 주도 설계(DDD)

도메인 주도 설계는 비즈니스 도메인을 중심으로 설계해서 문제를 해결하는 것을 목적으로 함

 

엔티티(Entity) : 하나의 객체

어그리거트(Aggregate) : 데이터 변경의 단위로 다루는 연관 엔티티 묶음(관련된 객체의 집합)

어그리거트 루트(Aggregate Root) : 집합에서 도메인의 중심을 의미하는 엔티티

 

 

DDD와 OOP의 차이점?

객체 지향은 상속이나 재활용성을 위해 공통 데이터를 공유하는 것을 중시한다.

도메인 주도는 도메인의 분리를 중시한다.

 

 

같은 용어라도 하위 도메인마다 의미가 다르고, 같은 대상이라도 지칭하는 용어가 다를 수 있다. 따라서 한 개의 모델로 모든 하위 도메인을 표현하는건 부적절하다.

 

각 모델들은 특정 컨텍스트 아래에서 완전한 의미를 갖는데, 이렇게 구분되는 경계를 갖는 컨텍스트를 Bounded-Context라고 한다.

 

 

컨텍스트(Context)

소프트웨어 시스템의 일부로서 비즈니스 문제 영역을 나타낸다.

 

도메인과 컨텍스트의 차이점 : 도메인은 특정 비즈니스 분야를 의미하지만 컨텍스트는 도메인 안에서 특정 비즈니스 문제 영역을 나타낸다.

(예: 은행 도메인의 대출 신청 컨텍스트)

 

DDD는 전체 도메인을 작은 단위로 분리하여 각 Bounded-Context를 식별하고 독립적으로 동작하도록 설계한다.

→ 전체 시스템의 복잡성을 줄이고 유연성을 높일 수 있다

 

 

당근같은 경우도 동일한 membership 사용자지만 판매자나 구매자로 지칭하는 용어가 다를 수 있다.

이런 도메인들은 비즈니스 문제 영역을 다루는 컨텍스트 아래에서 완전한 의미를 갖고, 서로 구분되는 경계를 갖는 컨텍스트를 Bounded-Context라고 한다.

 

 

Bounded-Context의 이점

1. 복잡한 시스템 구성요소를 쉽게 이해할 수 있다

2. 컨텍스트 단위로 작업

3. 시스템 규모가 커질수록 컨텍스트를 분리해 확장성

4. 팀간의 의사소통 간소화

 

 

분해라며? DDD는 왜 나온거야?

개별 팀이 상품(products)으로서 서비스를 소유하는 MSA의 핵심 개념과 일치해서 DDD를 주로 채택하기 때문이다.

 

우리는 Bounded-Context를 가질 수 있는 하위 도메인들을 각 서비스로 식별하도록 분해한다.

 

 

 

 

우리도 경계를 가지는 컨텍스트를 정의하고 서비스를 설계해보자. 기존 작업했던 resistance 프로젝트의 아키텍처를 그려보겠다. 

커맨드나 핫스팟, 정책 설정은... 순서대로 하다가 날려 먹었다.

 

도메인 이벤트(Domain Event) 작성

외부 시스템이 필요한 프로세스를 따로 추가해야한다.

 

 

예시로 작성한 이벤트는 게임 스테이지 시작시 친구를 동료로 선택하는 기능이다.

 

 

어그리거트(Aggregate) 정의

aggregate가 중복되는 이벤트들은 지워서 보기좋게 4개로 분해할 수 있었다.

 

 

Bounded-Context 정의

 

 

환율 도메인의 경우 사실 분리하는게 맞는데, 아직 별 다른 기능이 없는데 개별 서비스로 배포하는 것은 리소스 낭비라고 판단했다.

클래스 한두개 달랑 있는 서비스를 쿠버네티스에서 관리하는 것도 아깝다. 물론 비용적인 부분도 무시 못한다.

 

게시글 어그리거트와 합쳐서 dedicated 서비스로 정의했고 추후 업데이트를 통해 고도화시켜서 분리해서 확장할 계획이다.

 

 

오른쪽의 실제 배포된 서비스의 아키텍처와 동일한 것을 알 수 있다. 

 

dedicated 서비스는 게시글 관리 이외에도 환율 기능도 함께 담고 있다는 점에서(짬통 역할) 도메인별로 분리한 아키텍처라고 보긴 어렵다.

하지만 실제 업무가 그렇듯이 필요에 따라서 살짝 어겨도 된다고 생각한다.

 

MSA의 핵심 개념은 유연한 대응(Business Capability)이기에 비즈니스에 충실하는게 오히려 억지로 원칙을 고수하는 것보다 낫다고 느꼈다.

 

 

 

그 외에 추가.

wargame 프로젝트의 Bounded Context를 통한 마이크로서비스 분해