도메인 모델과 바운디드 컨텍스트

# 도메인 모델과 경계

- 도메인 모델을 만들 때 처음부터 완벽하게 단일 모델을 만들 수는 없음.

- 한 도메인은 다시 여러 하위 도메인으로 구분됨.

- 한 도메인을 논리적으로 같아 보여도 하위 도메인에 따라 다른 용어를 사용할 수 있음

- 하위 도메인마다 같은 용어라도 의미가 다르기 때문에 한 개의 모델로 모든 하위 도메인을 표현할 수 없음

- 올바른 도메인 모델을 개발하려면 하위 도메인 마다 모델을 다르게 만들어줘야

- 각 모델은 명시적으로 구분되는 경계를 가져야 함.

- 바운디드 컨텍스트 : 구분되는 경계를 갖는 컨텍스트

 

# 바운디드 컨텍스트

- 모델의 경계를 결정

- 하나의 바운디드 컨텍스트는 논리적으로 한 개의 모델을 가짐

- 이상적으로는 하위 도메인과 바운디드 컨텍스트가 일대일이면 좋겠으나, 현실에서는 1:N, N:1을 가지기도 함

- 즉, 조직 구조에 따라 바운디드 컨텍스트가 결정

 

- 여러 하위 도메인을 한  바운디드 컨텍스트에서 개발할 때는 하위 도메인의 모델에 섞이지 않게 해야

- 한 개의 바운디드 컨텍스트가 여러 하위 도메인을 포함하더라도 하위 도메인마다 구분되는 패키지를 가져야

- 바운디드 컨텍스트는 도메인 모델을 구분하는 경계가 되기 때문에 바운디드 컨텍스트는 구현하는 하위 도메인에 알맞은 모델을 포함해야

- 같은 도메인이더라도 컨텍스트마다 모델은 달라짐.

 

# 바운디드 컨텍스트 구현

- 바운디드 컨텍스트는 표현, 응용 서비스, 인프라 영역 모두 포함해야.

- 도메인 모델의 데이터 구조가 바뀌면 DB 테이블 스키마도 함께 변경해야 하기 때문

- 모든 바운디드 컨텍스트는 반드시 DDD로 구현할 필요 없이 단순 CRUD 방식으로 해도 됨.

- 두 방식을 혼합해서 사용할 수도 있음(CQRS)

- UI 서버를 통해 바운디드 컨텍스트를 위한 파사드 역할을 수행할 수도 있음

# 바운디드 컨텍스트 간 통합

- 인프라 영역에서 외부 시스템과의 연동을 처리

- RecSystemClient에서 도메인 모델 변환하는 작업을 처리

- 두 모델 간 변환 과정이 복잡하면 변환 처리를 위한 별도 클래스 생성 가능

- Rest API를 통해 두 바운디드 컨텍스트를 직접 통합할 수 있고, 메시지큐를 사용하여 간접적으로 통합할 수도 있음

- 비동기적으로 처리 가능

- 단, 두 바운디드 컨텍스트가 사용할 메시지의 데이터 구조를 맞춰야

- 변경 내용을 여러 컨텍스트에 pub-sub 가능

 

# 바운디드 컨텍스트 간 관계

- 호출자 : 상류, 피호출자 : 하류 관계로 의존

- 하류 컴포넌트는 상류 컴포넌트의 데이터와 기능에 의존

- pub/sub 관계 있는 두 팀은 상호 협력이 필수, 상류는 함부로 API를 변경할 수 없음

- 하류 팀이 다수 존재하면 여러 하류 팀의 요구사항을 수용할 수 있는 API를 만들고 이를 서비스 형태로 공개 : 공개 호스트 서비스

- 하류 컴포넌트는 상류 서비스 모델이 자신의 도메인 모델에 영향을 주지 않도록 보호해주는 완층 지대를 만들어야

- 안티 코럽션 계층(RecSystemClient)를 통해 다른 바운디드 컨텍스트의 모델에 영향을 받지 않고 내 도메인 모델을 유지할 수 있음.

 

## 다양한 바운디드 컨텍스트 통합 방식

 

### 공유 커널 방식

- 여러 팀이 공유하는 모델

- 관련된 중복 설계를 막을 수 있음

 

### 독립 방식

- 그냥 서로 통합하지 않음

- 서로 독립적임.

- 통합은 직접 수동으로 이루어짐

- 나중에 규모가 커지면 별도 통합 시스템 필요

# 컨텍스트 맵

- 전체 비즈니스를 조망할 수 있는 지도

- 하위 도메인이나 조직구조를 함께 표시하면 도메인을 포함한 전체 관계 이해하는데 도움됨