juniors-dev-study / domain-driven-design

1 stars 0 forks source link

14장 모델의 무결성 유지 (1) #15

Closed chanhyeong closed 3 years ago

chanhyeong commented 3 years ago

CONTEXT MAP - 프로젝트의 컨텍스트와 각 컨텍스트 간의 관계의 전체적인 개관 제공
BOUNDED CONTEXT - 각 모델의 범위 정의
CONTINOUS INTEGRATION - 모델의 단일화 유지


BOUNDED CONTEXT

무엇을 공유하고 무엇을 공유하지 않을지 명시하는 경계

모델은 컨텍스트에 적용

예제

BOUNDED CONTEXT: 예약

화물추적 시스템은 translation 을 통해 연동

화물선 운항 일정 관리는 BOUNDED CONTEXT 로 일하고 있는 것이 아님. SHARED KERNEL 이 대안

CONTINUOUS INTEGRATION

규모와 상관없이 통합된 시스템을 개발하기 위함

자동화된 테스트 + 구현 산출물을 merge 하는 프로세스 수립 + 끊임없는 UL 사용

CI 는 오직 하나의 BOUNDED CONTEXT 내에서만 필수적? -> translation 을 비롯한 인접한 context 와 관련된걸 똑같은 수준으로 다룰 필요는 없음
(외부 연동은 CI 가 필요 없다는건가 🤔)

CONTEXT MAP

BOUNDED CONTEXT 로는 전체를 볼 수 없음

프로젝트 상에 사용되는 모델 식별 + 각 BOUNDED CONTEXT 정의 (비 객체지향적인 하위 시스템에 대한 암시적인 모델 포함)

각 BOUNDED CONTEXT 에 이름 부여 + UL 의 일부로 포함

의사소통을 위해 컨텍스트 간 - 번역에 대한 윤곽을 명확하게 표현 + 공유해야 하는 정보 강조 => 경계 지점 서술

컨텍스트의 현재 영역을 나타내는 지도 작성

MAP 은 BOUNDED CONTEXT 의 명확한 이름을 제공해야 하고, 경계와 경계 특성을 명확하게 표현

CONTEXT MAP 은 항상 현재 상태 그대로의 상황을 표현

균열을 발견했다면 -> 지도에 모른다고 적고 서술 중단 -> 전체적인 뷰를 보고 혼란스러운 지점 설명

예제

Booking (예약) CONTEXT 와 Transport Network (운송망) 의 CONTEXT 간의 번역을 수행하는 Booking-Transport Network Translator

image

테스트가 중요하다

경계에 존재하는 번역의 미묘한 차이와 의사소통을 보완하는데 기여

통제할 수 없는 모델을 다룰 때 안심할 수 있음

CONTEXT MAP 의 조직화와 문서화

  1. BOUNDED CONTEXT 의 이름은 그 자체에 대해 말할 수 있어야 함. UL 에 들어가야 함
  2. 모든 사람들이 경계가 어디에 위치하는지 알아야하고, 어떠한 CONTEXT 도 인식할 수 있어야 함

팀 구성원이 모두 동일하게 개념적 경계를 이해하도록 의사소통을 활발히 하는게 필요 (위에 그림과 같은 간단한 다이어그램을 활용하는 등)

SHARED KERNEL

기능 통합에 한계가 있는 경우 CI 비용이 너무 높을 수 있음
+ CI 를 유지할 수 있는 기술, 조직이 갖춰지지 않거나 규모가 너무 큰 경우

CI 를 적용했을 때보다 더 많은 시간을 번역 계층을 개발하고 구조를 개선하는데 허비 + UL 구축 작업이 중복되고 UL 로 얻을 수 있는 이점을 잃어버릴 때

정리

변경 시 양 팀에서 작성한 모든 테스트를 통과해야함
KERNEL 의 복사본을 변경하고, 주기적으로 다른 팀의 복사본과 자신의 복사본을 통합

대부분 CORE DOMAIN 이거나, GENERIC SUBDOMAIN 의 일부 or 양쪽 모두
두 팀에 모두 필요한 부분이라면 모델의 어떤 부분이라도 SHARED KERNEL 이 될 수 있다
중복을 줄이고 두 하위 시스템 간의 통합을 용이하게 만드는 것이 목적

bearics commented 3 years ago

COUNDED CONTEXT : 모델 간의 경계를 만들고, 외부로부터 변화에도 모델의 일관성을 유지. CONTINUOUS INTEGRATION : 컨텍스트 내에서 파편화되지 않도록 응집성을 유지 CONTEXT MAP : 2개 이상의 컨텍스트 사이에서 번역을 해줌.(각 컨텍스트의 응집성을 유지하기 수월) SHARED KERNEL : CONTEXT MAP을 만드는 비용이 너무 많이 들경우에는 한 컨텍스트에서 부분집함을 공유함.(해당 부분 변경은 신중히)

궁금한 점들

y2o2u2n commented 3 years ago

BOUNDED CONTEXT

예) Charge 가 A 라는 BC 에서는 Customer Charge 인 반면, B 라는 BC 에서는 Supplier Charge 일 수 있다.

다른 강의에서 들은 건데, BC 를 나눈다고 하면 모놀리식일때는 상위 패키지를 나누는 방법과 멀티 모듈로 나누는 방법이 있고, 아예 프로젝트를 분리하여 마이크로 서비스로 나누는 방법도 있다고 함. BC 간 의존성을 끊어내기 위해서는 패키지로 나누는 방법은 좋지 않다고 들음.

AGGREGATE 와 헷갈릴 수 있는데, AGGREGATE 들은 BC 내에 존재한다. 지식인이라면 질문과 답변이 각각의 BC 이고, 질문과 질문에 달린 태그들이 질문 BC 안의 AGGREGATE 이지 않을까...? (라이프 사이클을 같이 하니까)

CI

BC 로 분리되었으니 그만큼 더 테스트에 신경 쓰고, 분리된 서비스를 안정적이게 배포하라는 말인듯

CONTEXT MAP

BOUNDED CONTEXT 간의 관계

관계의 대표적인 패턴은 아래와 같음

SHARED KERNEL

y2o2u2n commented 3 years ago

저도 아직 안 봤는데(ㅎㅎ...), 좋은 자료라고 해서 공유드려여...;

우아한 모노리스 - 발표 자료 우아한 모노리스 - 발표 영상

youngvly commented 3 years ago