[Week 8] 도메인 모델과 바운디드 컨텍스트 - 최인준

chap09/최인준.md

@@ -0,0 +1,72 @@
+## 도메인 모델과 경계
+
+- 한 도메인은 다시 여러 하위 도메인으로 구분되기 때문에 한 개의 모델로 여러 하위 도메인을 모두 표현하려고 시도하면 오히려 모든 하위 도메인에 맞지 않는 모델을 만들게 된다.
+- 논리적으로 같은 존재처럼 보이지만 하위 도메인에 따라 다른 용어를 사용하는 경우도 있다.
+    - ex) 회원 도메인의 회원, 주문 도메인의 주문자
+- 하위 도메인마다 사용하는 용어가 다르기 때문에 하위 도메인마다 모델을 만들어야 한다.
+- 모델은 특정한 컨텍스트 하에서 완전한 의미를 갖는다.
+- 같은 모델이라도 컨텍스트마다 의미가 서로 다르다. 이렇게 구분되는 경계를 갖는 컨텍스트를 **바운디드 컨텍스트**라고 한다.
+
+## 바운디드 컨텍스트
+
+바운디드 컨텍스트는 모델의 경계를 결정하며 한 개의 바운디드 컨텍스트는 논리적으로 한개의 모델을 갖는다.
+
+- 두 하위 도메인을 하나의 바운디드 컨텍스트에서 구현하기도 한다.
+- 여러 하위 도메인을 하나의 바운디드 컨텍스트에서 구현하기도 한다.
+    - 이 경우엔 하위 도메인의 모델이 섞이지 않도록 주의해야한다.
+    - 하위 도메인마다 구분되는 패키지를 갖도록 구현한다.
+- 바운디드 컨텍스트는 도메인 모델을 구분하는 경계가 되기 때문에 하위 도메인에 알맞는 모델을 가진다.
+
+## 바운디드 컨텍스트 구현
+
+바운디드 컨텍스트는 표현, 응용, 인프라 영역을 모두 포함한다.
+
+- 모든 바운디드 컨텍스트를 반드시 도메인 주도로 개발할 필요는 없다.
+- 도메인 로직을 갖지 않는 컨텍스트라면 DAO와 밸류 객체를 이용해 구현해도 된다.
+- 두 가지 방식을 모두 혼합해서 사용할 수 도 있다 → CQRS 패턴
+- 각 바운디드 컨텍스트는 서로 다른 구현 기술을 사용할 수도 있다.
+
+## 바운디드 컨텍스트 간 통합
+
+두 팀이 관련된 바운디드 컨텍스트를 개발하면 자연스럽게 두 바운디드 컨텍스트 간 통합이 발생한다.
+
+다음은 특정 바운디드 컨텍스트와 추천 기능을 위한 바운디드 컨텍스트 통합의 예시다.
+
+<img src="https://file.notion.so/f/f/412c9b0a-ec55-45df-8458-890f1703ea17/3bec0487-9c1f-4dbd-8aa4-bd6b480e67ed/Untitled.png?table=block&id=e0f54674-9506-432f-9c8c-e0e93b631509&spaceId=412c9b0a-ec55-45df-8458-890f1703ea17&expirationTimestamp=1723039200000&signature=uyP86eXNNG_2scEhlMJxF0SKlm43lENOX6KU2zOm-8U&downloadName=Untitled.png" width="50%" height="50%">
+
+- 외부 추천 시스템이 REST API를 제공하고 그 API를 활용한다.
+- 서로 일치하지 않는 모델을 구현했기 때문에 중간에 모델 변환 과정이 필요하다.
+- 이 변환과정을 맡은 클래스가 ACL역할도 한다.
+
+REST API를 호출하는 것은 두 바운디드 컨텍스트를 직접 통합하는 방식이다.
+
+간접 통합하는 방식은 **메시지 큐**를 활용하는 것이다.
+
+- 비동기로 메시지를 처리하기 때문에 메시지 큐에 필요한 것을 추가한 뒤에 기다리지 않고 이어서 자신의 작업을 처리할 수 있다.
+- 두 바운디드 컨텍스트가 사용할 메시지의 데이터 구조를 맞춰야 한다.
+    - 팀 간의 협의가 필요하다.
+
+## 바운디드 컨텍스트 간 관계
+
+두 바운디드 컨텍스트를 통합할 때 REST API를 많이 활용하는데 API를 사용하는 바운디드 컨텍스트는 제공하는 바운디드 컨텍스트에 의존하게 된다.
+
+- 두 바운디드 컨텍스트는 고객/공급자 관계를 갖는다.
+- 두 팀은 상호협력이 필수적이다.
+    - 한 쪽에서 협의 없이 무언가를 하면 다른 한 쪽이 곤란해진다.
+- 상류(공급자) 컴포넌트는 통신 프로토콜을 정의하고 이를 공개한다.
+- 하류(고객) 팀이 다수 존재하면 상류 팀은 여러 하류팀의 요구사항을 수용할 수 있는 API를 만든다.
+    - 서비스의 일관성을 유지할 수 있게 해준다.
+    - “공개 호스트 서비스”라고 한다.
+
+- 두 바운디드 컨텍스트가 모델을 공유하는 경우도 있다.
+    - 이 모델을 공유 커널이라고 부른다.
+
+## 컨텍스트 맵
+
+- 개별 바운디드 컨텍스트에 매몰되면 전체를 보지 못할 때가 있다.
+- 이를 방지하기 위해선 컨텍스트 맵이 필요하다.
+
+<img src="https://file.notion.so/f/f/412c9b0a-ec55-45df-8458-890f1703ea17/e5686fff-c22c-4fc0-9793-acb067d8f619/Untitled.png?table=block&id=01ec82bb-29fd-4e35-a28e-358a5d3b6965&spaceId=412c9b0a-ec55-45df-8458-890f1703ea17&expirationTimestamp=1723039200000&signature=04MOQvXp8Ap_g4y9PRfXJEyAdCh9Cth22jOVtwDTzRE&downloadName=Untitled.png" width="50%" height="50%">
+
+- OHS : 공개 호스트 서비스
+- ACL : 안티코럽션 계층