도메인 주도 설계 첫걸음 - 3장, 4장

 

03. 도메인 복잡성 관리

• 도메인에 대한 모든 이해관계자가 의사소통에 사용할 수 있는 유비쿼터스 언어를 개발하는 것이 중요
• 내부 동작과 기본원칙에 대한 도메인 전문가의 멘탈 모델을 반영해야 함
• 그러나 조직 규모에 따라 멘탈 모델은 일관성이 없을 수 있음

 

일관성 없는 모델

본 책에서는 lead(리드)라는 용어가 마케팅 부서와 영업 부서에서 다른 의미로 사용되는 예시를 보여준다.

마케팅 부서

• 리드 : 누군가가 제품 중 하나에 관심이 있다는 이벤트(알림)

영업 부서

• 리드 : 영업 프로세스의 전체 수명주기 (장기적 진행 과정)

따라서 두 부서의 도메인 전문가 사이에는 '리드'의 멘탈 모델은 차이가 존재

• 이는 실제로 다른 부서의 사람들 사이에서 의사소통이 어려울 수 있지만,
• 사람들이 서로 상호작용하면서 정확한 의미를 추론하는 것은 쉽다(?) - p36
  • 문맥적으로 글이 매끄럽지 않음 이해 못하겠다.
• 다양한 비즈니스 모델은 사람들간의 상호작용에서 이해하기 쉽지만, SW로 표현하는 것은 더 어려움
  • 소스 코드는 모호성에 잘 대처하지 못한다.

 

이러한 유비쿼터스 언어 공식화에 대한 전통적인 솔루션 방법들

1. 모든 종류의 문제에 대해 단일 모델을 설계하는 방식

• 모든 종류에 대해 단일 모델을 생성하므로, 문제 해결에 대한 다양한 복잡성이 존재한다.
  • 관련 없는 세부사항 필터링 복잡성
  • 필요한 것을 찾는 복잡성
  • 데이터 일관성 유지에 대한 복잡성

'이것저것 다 잘하는 사람은 단 한 분야에서도 달인이 될 수 없다'

2. 문맥에 따른 용어 앞 접두사(prefix) 추가 방식

• 해당 방법은 두 모델을 코드로써 생성 가능하게 함
• 단점 :
  • 1. 인지 부하 발생 : 각 모델을 언제 사용해야 하는 지, 구현할 수록 실수 유발 가능성 높아짐
    2. 모델의 구현이 유비쿼터스 언어와 일치하지 않음 : 커뮤니케이션에서 아무도 접두사를 사용하지 않음

해당 딜레마를 해결해 줄 방법 : 도메인 주도 설계 패턴 - 바운디드 컨텍스트

 

Bounded Context

 

바운디드 컨텍스트

• 유비쿼터스 언어를 여러 작은 언어로 나눠 각 언어를 적용할 수 있는 명시적인 바운디드 컨텍스트에 할당
• 각 바운디드 컨텍스트에서 단일 의미를 가지며, 이는 세분화된 유비쿼터스 언어 각각 일관성을 띄게 된다
• 바운디드 컨텍스트 : 유비쿼터스 언어의 일관성이 유지되는 경계
• 기대효과 : 컨텍스트를 명시적이고 중요한 비즈니스 도메인의 요소로 모델링 가능

 

모델 경계

• 모델 : 복잡한 시스템을 이해하는데 도움을 주기 위한 구조화
• 우리가 해결하려는 문제 = 모델 본연의 목적
• 모델의 경계(바운디드 컨텍스트)를 정의하는 것 - 모델링 프로세스의 본질적 부분

 

정제된 유비쿼터스 언어

• 유비쿼터스 언어는 바운디드 컨텍스트 경계 안에서만 보편적으로 적용
• 유비쿼터스 언어는 바운디드 컨텍스트 포함된 모델을 설명하는 데만 집중

 

바운디드 컨텍스트의 범위

• 서로 다른 도메인 전문가들은 동일한 비즈니스 엔티티에 대해 상충되는 멘탈 모델을 가지고 있음
• 유비 쿼터스 언어의 일관성은 해당 언어의 가장 넓은 경계를 식별하는 데 도움이 될 뿐
  • 일관성이 없는 모델과 용어가 있기 때문에 더 커질 수 없음
• 하지만, 바운디드 컨텍스트를 기준으로 분해는 가능

 

바운디드 컨텍스트 정의

• = 유비쿼터스 언어의 범위를 정의하는 것
• 전략적인 설계 의사 결정
• 바운디드 컨텍스트의 크기 자체는 의사결정 요소는 아니다
  • 유비쿼터스 언어의 경계는 넓을수록 일관성을 유지하기는 어려움
  • 바운디드 컨텍스트를 괜히 작게 만들기 위해 노력하는 것은 설계를 통합하는데 오버헤드가 커질 수 있다.
• 따라서 컨텍스트의 크기 결정 : 문제 도메인이 무엇이냐에 따라 달라진다.

 

세분화된 바운디드 컨텍스트 추출 이유

• 일부 컴포넌트 개발 수명주기 분리
  • 새로운 SW 팀 구성
  • 시스템 일부 비기능 요구사항 해결
• 바운디드 컨텍스트의 나머지 기능과 독립적으로 확장할 수 있기 때문에
• 모델을 유용하게 유지하고 바운디드 컨텍스트의 크기를 비즈니스 요구사항과 조직의 제약사항에 맞춰라

 

바운디드 컨텍스트 vs 하위 도메인

비즈니스 도메인은 두가지 기준으로 분해 가능

• 여러 하위 도메인 (세분화된 문제 도메인)
• 바운디드 컨텍스트 집합

하위 도메인

• 조직이 일하고 경쟁 전략을 계획하는 방법이 결정된다.
• 정의는 : 비즈니스 담당자가 담당
  • 소프트웨어 엔지니어는 하위 도메인을 식별하기 위해 비즈니스 도메인을 분석할 뿐

바운디드 컨텍스트

• SW 엔지니어에 의해 설계 된다.
• 모델의 경계 선택 = 전략적 설계의 의사결정

하위도메인과 바운디드 컨텍스트 상호작용

• 소규모 시스템 : 단일 모델에 전체 비즈니스 도메인에 적용가능 (모놀리식 바운디드 컨텍스트)
  • 하지만 좀 비현실적
• 모델이 여전히 크고 유지보수가 어려운 경우 : 더 작은 바운디드 컨텍스트로 분해 가능
• = 각 하위 도메인에 대한 바운디드 컨텍스트로 나눌 수 있음
• 바운디드 컨텍스트와 하위 도메인의 설계가 1:1 매핑
  • 유연성 하락
  • 바운디드 컨텍스트 안에서 하나의 하위 도메인 모델만 사용된다

하위 도메인

• 발견되는 것
• 비즈니스 전략에 의해 정의

바운디드 컨텍스트

• 설계하는 것
• SW 엔지니어가 특정 프로젝트의 컨텍스트와 제약 조건을 해결하기 위해 설계

 

경계

바운디드 컨텍스트 패턴 : 물리적 경계 / 소유권 경계를 규정하기 위한 도메인 주도 설계 도구

 

물리적 경계

• 바운디드 컨텍스트 : 모델 경계 + 구현하는 시스템의 물리적 경계 역할
• 즉, 구현, 버전 관리 등에 대해 각각의 다른 바운디드 컨텍스트와 독립적 실행
• 바운디드 컨텍스트는 여러 하위 도메인을 포함할 수 있다.
• 바운디드 컨텍스트 = 물리적 경계 / 하위 도메인 = 논리적 경계

소유권 경계

• 바운디드 컨텍스트 : 한 팀에서만 구현, 발전, 유지 관리해야 함
• 팀과 바운디드 컨텍스트 간의 관계 = 단방향
  • 단일 팀이 여러 바운디드 컨텍스트를 소유하는 것은 가능

 

실생활의 바운디드 컨텍스트

시맨틱 도메인(semantic domain)

• 의미 영역과 해당 의미를 전달하기 위해 사용하는 단어 영역으로 구분
• ex) monitor, port, processor
• 모델 : 당면한 작업과 관련 없는 정보는 생략해야 한다

 

결론

• 유비쿼터스 언어는 여러 바운디드 컨텍스트로 분해해야 한다.
• 유비쿼터스 언어 : 바운디드 컨텍스트의 범위 내에서 일관성을 가져야 함
• 그러나 서로 다른 바운디드 컨텍스트에서는 동일한 용어라도 다른 의미를 가질 수 있다
• task : 1) 하위 도메인이 발견되면 2) 바운디드 컨텍스트도 설계
• 바운디드 컨텍스트 & 유비쿼터스 언어는 한 팀에서 만들고 유지보수
• 바운디드 컨텍스트는 서비스, 하위 시스템 등의 물리적 구성요소로 분해
• 각 바운디드 컨텍스트의 수명주기는 서로 독립적

 

 

04. 바운디드 컨텍스트 연동

• 바운디드 컨텍스트 패턴 : 일관성 유지 / 모델링 가능하게 함
• 다른 바운디드 컨텍스트가 동일한 비즈니스 엔티티 대표 가능
  • 각 두 바운디드 컨텍스트는 다른 문제를 해결하는 비즈니스 도메인을 모델링
• 다른 바운디드 컨텍스트는 서로 독립적 발전 및 구현 가능
• 바운디드 컨텍스트 자체는 독립적이지 않음 (바운디드 컨텍스트간의 상호작용)
• 컨트랙트 : 바운디드 컨텍스트 간의 접점

바운디드 컨텍스트의 관계(연동)에 따른 패턴

• 협력
• 사용자-제공자
• 분리형 노선

 

협력형 패턴 그룹

• 협력 및 소통이 잘 되는 팀에서 사용
• 적합한 요건 : 팀의 커뮤니케이션 & 협업
• 종류 :
  • 파트너십 패턴
  • 공유 커널 패턴

 

파트너십 패턴

• 바운디드 컨텍스트 간 애드혹(ad-hoc) 방식으로 조정

ad-hoc : 특별한 목적을 위해서

• 연동의 조정 : 양방향
• 잘 구축된 협업 실무, 높은 수준의 헌신, 잦은 동기화 필수
• 지리적으로 가까운 팀일수록 유리

 

공유 커널 패턴

• 하위 도메인의 동일 모델 혹은 그 일부가 여러 다른 바운디드 컨텍스트에서 구현되는 경우
• 공유 커널 :두 바운디드 컨텍스트가 공통으로 사용하는 권한 모델
• 공유 모델은 두 바운디드 컨텍스트의 일관성이 유지되어야 한다.
• 각 바운디드 컨텍스트는 권한 모델을 수정할 수 있고, 해당 변경은 모든 바운디드 컨텍스트에 영향을 준다.
• 파트너십 패턴에 비해 협력적이지 X
• 바운디드 컨텍스트의 경계 소유권을 위반한 패턴

공유 범위

• 공유 모델의 변경은 다른 모든 바운디드 컨텍스트에 즉시 영향
• 주의점 : 연쇄 영향 최소화를 위해 공통으로 구현돼야 하는 모델의 일부분만 노출하도록 해야함

구현

• 공유 커널 - 모든 바운디드 컨텍스트에 즉시 반영되도록 구현
• 영향을 받는 모든 바운디드 컨텍스트에 연동 테스트 수행

사용해야 하는 경우

• 중복 비용 > 조율 비용
  • 공유하는 코드베이스에 대한 변경을 조율하는 노력보다 공유하는 모델에 대한 변경을 통합할 때 드는 노력이 클 때

통합 비용과 중복 비용의 차이

• 모델의 변동성에 따라 달라짐
• 변경이 잦을수록 통합 비용 증가

• 적절한 조율 없이 밀접하게 연결된 기능을 구현해야 할 때 (조직의 정치적 문제 & 지리적 문제)
• 레거시 시스템 개선 시
• 동일 팀에서 소유하고 구현한 바운디드 컨텍스트 연동 시 : 자연스레 파트너십 패턴으로 가기도 함

 

사용자 - 제공자 패턴 그룹(customer - supplier)

• 서비스 제공자 : upstream / 사용자 : downstream
• 협력 그룹과의 차이 :
  • 양 팀은 서로 독립적 성공 가능
  • 연동 컨트랙트를 주도하는 권력의 불균형 존재
• 권력의 불균형에 따라 패턴이 나뉨
  • 순응주의자
  • 충돌방지 계층
  • 오픈 호스트 서비스 패턴

순응주의자 패턴

• 힘의 균형이 : 제공자에게 있는 경우(upstream)
• 다운 스트림을 신경써도 되지 않는 경우(잘 구축된 모델 / 산업 표준 / 다운스트림의 요건 충분)

충돌 방지 계층 패턴

• 다운스트림에서 충돌 방지 계층을 통해 업스트림의 바운디드 컨텍스트 모델을 스스로 필요에 맞고 가공
• ex)
  • 다운스트림 바운디드 컨텍스트가 핵심 하위 도메인을 포함할 경우
  • 업스트림 모델이 사용자의 요건에 비효율적이거나 불편한 경우
  • 제공자가 컨트랙트를 자주 변경할 경우 (보호하기 위해)

오픈 호스트 서비스 패턴 (OHS)

• 힘이 사용자 측에 있을 경우
• 제공자는 구현 모델 분리에 대해 사용자 보호를 위해, 퍼블릭 인터페이스와 구현 모델을 분리
• 퍼블릭 인터페이스 : 유비쿼터스 언어를 따름 & 연동지향 언어를 통해 편리한 프로토콜을 노출
  • 이러한 퍼블릭 프로토콜 = 공표된 언어(published Language)
• 충돌 방지 계층 패턴의 반대
• 

분리형 노선

오픈 호스트 서비스 패턴 (OHS)

• 협업 의지가 없거나, 협업할 수 없는 경우
• 커뮤니케이션 이슈 / 일반 하위 도메인 / 모델의 차이

핵심 하위 도메인을 연동할 경우, 협업 없는 분리형 노선은 피해야 함
하위 도메인의 중복 구현은 전략을 효과적이고 효율적으로 구현하는 것을 어렵게 함

 

컨텍스트 맵

• 바운디드 컨텍스트 간의 연동을 시각적 표현
  
  
• 컨텍스트 맵 표시의 이점
  • 거시적 설계 관점 제공
  • 커뮤니케이션 패턴 묘사
  • 조직적 문제 통찰력 제공

 

연습 문제

• 다운스트림 하위 도메인 중 충돌 방지 계층을 구현할 가능성이 가장 높은 것 : 핵심 하위 도메인
• 업스트립 하위 도메인 중 오픈 호스트 서비스를 구현할 가능성이 가장 높은 것 : 핵심 하위 도메인