From 711cf165889b8db6456857de0ab7c5a7d57e93b0 Mon Sep 17 00:00:00 2001 From: dlswns2480 Date: Tue, 6 Aug 2024 22:15:24 +0900 Subject: [PATCH] =?UTF-8?q?docs=20:=209=EC=9E=A5?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../\354\265\234\354\235\270\354\244\200.md" | 72 +++++++++++++++++++ 1 file changed, 72 insertions(+) create mode 100644 "chap09/\354\265\234\354\235\270\354\244\200.md" diff --git "a/chap09/\354\265\234\354\235\270\354\244\200.md" "b/chap09/\354\265\234\354\235\270\354\244\200.md" new file mode 100644 index 0000000..67be24e --- /dev/null +++ "b/chap09/\354\265\234\354\235\270\354\244\200.md" @@ -0,0 +1,72 @@ +## 도메인 모델과 경계 + +- 한 도메인은 다시 여러 하위 도메인으로 구분되기 때문에 한 개의 모델로 여러 하위 도메인을 모두 표현하려고 시도하면 오히려 모든 하위 도메인에 맞지 않는 모델을 만들게 된다. +- 논리적으로 같은 존재처럼 보이지만 하위 도메인에 따라 다른 용어를 사용하는 경우도 있다. + - ex) 회원 도메인의 회원, 주문 도메인의 주문자 +- 하위 도메인마다 사용하는 용어가 다르기 때문에 하위 도메인마다 모델을 만들어야 한다. +- 모델은 특정한 컨텍스트 하에서 완전한 의미를 갖는다. +- 같은 모델이라도 컨텍스트마다 의미가 서로 다르다. 이렇게 구분되는 경계를 갖는 컨텍스트를 **바운디드 컨텍스트**라고 한다. + +## 바운디드 컨텍스트 + +바운디드 컨텍스트는 모델의 경계를 결정하며 한 개의 바운디드 컨텍스트는 논리적으로 한개의 모델을 갖는다. + +- 두 하위 도메인을 하나의 바운디드 컨텍스트에서 구현하기도 한다. +- 여러 하위 도메인을 하나의 바운디드 컨텍스트에서 구현하기도 한다. + - 이 경우엔 하위 도메인의 모델이 섞이지 않도록 주의해야한다. + - 하위 도메인마다 구분되는 패키지를 갖도록 구현한다. +- 바운디드 컨텍스트는 도메인 모델을 구분하는 경계가 되기 때문에 하위 도메인에 알맞는 모델을 가진다. + +## 바운디드 컨텍스트 구현 + +바운디드 컨텍스트는 표현, 응용, 인프라 영역을 모두 포함한다. + +- 모든 바운디드 컨텍스트를 반드시 도메인 주도로 개발할 필요는 없다. +- 도메인 로직을 갖지 않는 컨텍스트라면 DAO와 밸류 객체를 이용해 구현해도 된다. +- 두 가지 방식을 모두 혼합해서 사용할 수 도 있다 → CQRS 패턴 +- 각 바운디드 컨텍스트는 서로 다른 구현 기술을 사용할 수도 있다. + +## 바운디드 컨텍스트 간 통합 + +두 팀이 관련된 바운디드 컨텍스트를 개발하면 자연스럽게 두 바운디드 컨텍스트 간 통합이 발생한다. + +다음은 특정 바운디드 컨텍스트와 추천 기능을 위한 바운디드 컨텍스트 통합의 예시다. + + + +- 외부 추천 시스템이 REST API를 제공하고 그 API를 활용한다. +- 서로 일치하지 않는 모델을 구현했기 때문에 중간에 모델 변환 과정이 필요하다. +- 이 변환과정을 맡은 클래스가 ACL역할도 한다. + +REST API를 호출하는 것은 두 바운디드 컨텍스트를 직접 통합하는 방식이다. + +간접 통합하는 방식은 **메시지 큐**를 활용하는 것이다. + +- 비동기로 메시지를 처리하기 때문에 메시지 큐에 필요한 것을 추가한 뒤에 기다리지 않고 이어서 자신의 작업을 처리할 수 있다. +- 두 바운디드 컨텍스트가 사용할 메시지의 데이터 구조를 맞춰야 한다. + - 팀 간의 협의가 필요하다. + +## 바운디드 컨텍스트 간 관계 + +두 바운디드 컨텍스트를 통합할 때 REST API를 많이 활용하는데 API를 사용하는 바운디드 컨텍스트는 제공하는 바운디드 컨텍스트에 의존하게 된다. + +- 두 바운디드 컨텍스트는 고객/공급자 관계를 갖는다. +- 두 팀은 상호협력이 필수적이다. + - 한 쪽에서 협의 없이 무언가를 하면 다른 한 쪽이 곤란해진다. +- 상류(공급자) 컴포넌트는 통신 프로토콜을 정의하고 이를 공개한다. +- 하류(고객) 팀이 다수 존재하면 상류 팀은 여러 하류팀의 요구사항을 수용할 수 있는 API를 만든다. + - 서비스의 일관성을 유지할 수 있게 해준다. + - “공개 호스트 서비스”라고 한다. + +- 두 바운디드 컨텍스트가 모델을 공유하는 경우도 있다. + - 이 모델을 공유 커널이라고 부른다. + +## 컨텍스트 맵 + +- 개별 바운디드 컨텍스트에 매몰되면 전체를 보지 못할 때가 있다. +- 이를 방지하기 위해선 컨텍스트 맵이 필요하다. + + + +- OHS : 공개 호스트 서비스 +- ACL : 안티코럽션 계층 \ No newline at end of file