9장 도메인 모델과 바운디드 컨텍스트 2부

https://www.notion.so/9-2-f46f116cce4745a09a32a815fc297323

Bounded Context간의 관계

출처: https://minkukjo.github.io/dev/2020/11/11/DDD-09/

• Bounded Context는 다양한 방식으로 관계를 맺는다.

• 두 Bounded Context간 관계중 흔한 관계는 한쪽에서 API를 제공하고 다른 한쪽에서 그 API를 호출하는 관계다. 대표적인게 REST API 다.

• 이것을 공급자/고객 관계라고 한다.

• 공급자는 상류 컴포넌트, 고객은 하류 컴포넌트라고 칭한다.

• 상류 컴포넌트가 제공하는 데이터를 하류 컴포넌트가 의존한다.

• 하류는 상류에 의존하므로 상류가 제공하는 인터페이스가 바뀌면 하류의 코드도 바뀐다.

• 상류는 보통 하류가 사용할 수 있는 통신 프로토콜을 정의하고 이를 공개한다.

• 예를 들어 상류는 하류가 사용할 수 있는 REST API를 제공할 수 있다.

• 상류의 고객인 하류가 다수 존재하면 상류는 여러 하류의 요구사항을 수용할 수 있는 API를 만들고 이를 서비스 형태로 공개해서 서비스의 일관성을 유지할 수 있다.

• 이런 서비스를 가리켜 공개 호스트 서비스 (OPEN HOST SERVICE) 라고 한다.

출처: https://minkukjo.github.io/dev/2020/11/11/DDD-09/

• 이런 서비스의 대표적인 예가 검색이다.

• 블로그, 카페, 게시판과 같은 서비스를 제공하는 포탈은 각 서비스 별로 검색 기능을 구현하기 보다는 검색을 위한 전용 시스템을 구축하고 검색 시스템과 각 서비스를 통합한다.

• 이때 검색은 상류 컴포넌트 가 되고 블로그 카페 게시판은 하류 컴포넌트가 된다.

• 상류 컴포넌트는 각 하류 컴포넌트의 요구사항을 수용하는 단일 API를 만들어 이를 공개하고 각 하류팀은 공개된 API를 사용해서 검색 기능을 구현하게 된다.

• 상류 컴포넌트의 서비스는 상류 Bounded Context를 따르므로 하류는 하류 Bounded Context가 오염되지 않게 막아주도록하는 완충지대를 만들어야 한다.

출처: https://nesoy.github.io/articles/2018-07/DDD-Bounded-Context

• 이 그림에서 RecSystemClient는 외부 시스템과 연동을 처리하는데 외부 시스템의 도메인 모델이 내 도메인 모델을 침범하지 않도록 하는 역할을 한다.

• 즉 이것이 안티코럽션 계층이 된다.

• 두 Bounded Context가 같은 모델을 공유하는 경우도 있다.

• 예를 들어 운영자를 위한 주문 관리 도구를 개발하는 팀과 고객을 위한 주문 서비스를 개발하는 팀이 다르다고 가정하자.

• 이 두팀은 주문을 표현하는 모델을 공유함으로써 주문과 관련된 중복 개발을 막을 수 있다.

• 이렇게 두팀이 공유하는 모델을 공유 커널 이라고 부른다

• 공유 커널의 장점은 중복을 줄여준다는 것

• 하지만 두팀이 한 모델을 공유하기 때문에 한 팀에서 임의로 모델을 변경하면 안된다.

• 그래서 두팀이 밀접한 관계를 유지하며 계속 소통 해야한다.

• 두팀이 소통이 안되면 공유 커널로 인한 장점보다 단점이 더 많아진다.

• 독립방식 관계

• 이 관계는 아예 두 Bounded Context를 통합하지 않는 방식이다.

• 그러므로 서로 독립적으로 발전시켜 나간다.

출처: https://minkukjo.github.io/dev/2020/11/11/DDD-09/

• 예를 들어 온라인 쇼핑몰 솔루션과 외부의 ERP 서비스를 사용하고 있다고 하자.

• 온라인 쇼핑몰 솔루션은 외부 ERP 서비스와의 연동을 지원하지 않으므로 온라인 쇼핑몰에서 판매가 발생하면 쇼핑몰 운영자는 쇼핑몰 시스템에서 판매 정보를 보고 ERP 시스템에 입력해야 한다.

• 수동으로 통합하는 방식은 규모가 커질수록 한계가 있다.

• 그러므로 결국 통합해야 한다.

출처: https://minkukjo.github.io/dev/2020/11/11/DDD-09/

• 이때 외부에서 구매한 솔루션과 ERP를 완전히 대체할 수 없다면 두 Bounded Context를 통합해주는 별도의 시스템 (번역기) 을 만들어야 할 수도 있다.

컨텍스트 맵

• 개별 Bounded Context에 매몰되면 전체를 보지 못할때가 있다.

• 나무만 보다 숲을 보지 못하는 상황을 방지하려면 전체 비지니스를 조망할수 있는 지도가 필요한데 그것이 컨텍스트 맵이다.

• 그림만봐도 한눈에 각 Bounded Context의 경계가 명확하게 드러나도 서로 어떤 관계를 맺고 있는지 알 수 있다.

• Bounded Context 영역에 주요 애그리것을 함께 표시하면 모델에 대한 관계가 더 명확히 드러난다.

출처: https://minkukjo.github.io/dev/2020/11/11/DDD-09/

• 컨텍스트맵은 시스템의 전체 구조를 보여준다. 이는 하위 도메인과 일치하지 않는 Bounded Context를 찾아 도메인에 맞게 Bounded Context를 조절하고 사업의 핵심 도메인을 위해 조직 역량을 어떤 Bounded Context에 집중할지 파악하는데 도움을 준다.

• 컨텍스트 맵은 따로 그리는 규칙은 없다.

• 간단한 도형과 선을 이용해서 각 컨텍스트의 관계를 이해할수 있는 수준에서 그리면 된다.

(Published Language등이 책에 없다.)

Uploaded by Notion2Tistory v1.1.0