1. 큰그림

- 조직의 전체 도메인은 여러개의 서브도메인으로 이루어져 있다

- 모델은 바운디드 커텍스트 안에 만들어진다.


1.1 서브도메인과 바운디드 커텍스트의 활용


- 직선은 바운디드 컨텍스트, 점선은 서브도메인을 나타낸다

- 두개의 물리적 시스템이 있고 하나의 외부 시스템이 있다. 

- 논리적으로 여러개의 서브 도메인으로 구성되어 있지만 안타깝게 하나의 시스템이다.

- 아래 그림에서 e-Commerce System 바운디드 컨텍스트는 고객과 같은 도메인이 각 서브 도메인에서 중복되서 사용될 수도 있어 혼란이 발생한다. 언어적으로 잘 분리된 컨텍스트는 아니다.


Image result for subdomain bounded context

그림 1. 서브도메인과 바운디드 컨텍스트를 포함한 도메인


2.1 핵심 도메인에 집중하기

- 아래 그림은 도메인을 바라보는 추상적인 뷰이다. 

- 핵심 도메인은 그 조직의 비즈니스의 성곡을 지속시키기위해 가장 중요한 도메인이다.

- 필수이지만 핵심이 아니면 지원 도메인이라 하자.

- 핵심 도메인의 구현에 집중해라.

- 아래 그림은 도메인 Template이다 활용하자.

Image result for subdomain bounded context


그림 2. 서브도메인과 바운디드 컨텍스트를 포함하는 추상적인 비즈니스 도메인


2. 왜 전략적 설계가 엄청나게 필수적인가

- 엔티티(Entity) 와 값 개체(Value Object) 에 초첨을 맞추면 큰그림의 비전을 가릴 수 있다.

- 팀은 전략적 모델링의 사고방식을 가져야한다.

* 바운디드 컨텍스트 이름 짓기

 - 모델 이름 컨텍스트 와 같은 형태(name-of-model Context).

 - 협업 컨텍스트, 식별자와 액세스 컨텍스트, 애자일 컨택스트 등


3. 현실의 도메인과 서브 도메인

- 도메인은 문제점 공간(Problem Space)와 해결책 공간(Solution Space)를 모두 가지고 있다.

- 문제점 공간은 핵심 도메인을 만들기위해 개발하는 전체 도메인의 일부

- 해결책 공간은 하나이상의 바운디드 컨텍스트이며 구체적인 소프트웨어 모델의 집합

Image result for bounded context account


4. 바운디드 컨텍스트 이해하기

- 바운디드 커텍스트는 명시적이고 언어적이다.

- 모든 것을 포함하는 모델을 생성하려는 것은 함정이다. 은행 컨텍스트와 문학적 컨텍스트에서 어카운트(Account)의 의미는 다르다.

- 컨텍스트가 왕이다.

 * 일반적으로 용어가 컨택스트마다 혼용되어 사용되는 것은 사실이다. 은행과 문학적 컨택스트는 완전이 별개의 공간이라고 봐도 좋지만 하나의 용어를 다른 컨택스트에거 다른 용어로 사용하는 일도 발생할 것으로 보인다. 이럴때 용어의 통일은 필요하지 않을까? => 같은 팀에서 작업한다면 분명 통일하는 것이 좋을 것으로 보인다. 하지만, 다른팀이라면 문제 될 일이 없을 것으로 보인다. (17.12.07)

 

Image result for bounded context account


4.1 모델 그 이상을 위해

- 바운디드 컨텍스트는 도메인 모델(일반적으로 영속성 데이터베이스 스키마)도 캡슐화 한다.

- 하지만, 이는 도메인 모델과 상호작용과 도메인 모델을 지원을 위한 다른 요소를 포함한다.

- 즉, 모델 또는 스키마에 집착하지 말고 큰 그림으로서 상호작용을 도메인 모델에 담아야 한다는 뜻으로 풀이된다.


4.2 바운디드 컨텍스트의 크기

- 바운디드 컨텍스트는 완전한 유비쿼터스 언어를 표현하기 위해 필요한 크기만큼 커야 한다.

- 플랫폼, 프레임워크, 컴포넌트 등 아키텍처적 영향으로 기술적 경계를 그어서도 안된다.

- 가용한 개발자 리소스로 작업 분배를 위해서도 안된다.

- 너무 성급하게 최소화 하지 말아라. 바운디드 컨텍스트의 크기를 신중히 생각하자.


4.3 기술적 컨텍스트로 정력하기

- 이클립스, 인텔리J 등을 사용할때 하나의 바운디드 컨텍스트는 하나의 프로젝트 안에 머문다.

- 하나의 바운디드 컨텍스트 안에서는 하나의 팀만 작업한다.

- 최상위 모듈 예: com.mycompany.optimalpurchasing

- 하위 패키지: com.mycompany.optimalpurchasing.presentation

com.mycompany.optimalpurchasing.application

com.mycompany.optimalpurchasing.domain.model

com.mycompany.optimalpurchasing.infrastructure

==> 일반적으로 spring boot에서 represent, controller, domain, repository 로 나뉜다. 


5. 샘플 컨텍스트

- 결국 가장 이상적인 방식으로 각각의 서브도메인과 1:1 로 정렬된다.

Image result for domain driven design implementation sample context


5.1 협업 컨텍스트

- 초기 모델에서 식별자 및 액세스 바운디드 컨텍스트와 통합이 되어 있었다.

- 결과적으로 보안 모델인지 협업 모델일지 알수가 없었다.

- User와 Permission에 얽힘을 제거하고 엄격하게 협업에만 집중


5.2 식별자와 액세스 컨텍스트

- 이벤트 모델을 통해 User와 Permission의 변경을 알린다.

- Admin/Seller 의 경우 Tenant를 분리하고 하나의 모듈을 사용해도 될것으로 보인다.


5.3 애자일 프로젝트 관리 컨텍스트

- 추가 기능을 협업에 넣는 실수는 다시 하지 않는다.


'디지털 양피지 > Domain Driven Design' 카테고리의 다른 글

3. 컨텍스트 맵  (0) 2017.12.08
1. DDD를 시작하며  (0) 2017.11.29
DDD의 큰 그림  (0) 2017.11.29
Posted by 빨간 양말