도메인 주도 설계 핵심 1-2장

---

Chap1. 나에게 도메인 주도 설계는

DDD (Domain Driven Design, 도메인 주도 설계)

DDD는 소프트웨어 개발에 대한 복잡한 접근법이라기보다, 
복잡한 소프트웨어 프로젝트에 사용할 수 있는 수준 높은 기술들을 모은 것이다.
그러니까, 복잡함을 간단히 풀어줄 수 있는 방법으로 생각하는 게 맞겠다.
오히려 너무 단순한 프로젝트에 DDD 를 도입하면 복잡성을 증가시킬 수도 있겠다.
 

설계의 중요성

설계는 필연적이다. 설계하지 않는 것은 각자 다른 설계를 하고 이를 하나로 뭉뚱그리는 것을 만들 뿐이다.
모델링이라고 인정하든 인정하지 않든 우리는 모델링을 한다.
설계를 제대로 하지 않으면 앞으로 유지보수하는 데에 훨씬 더 많은 비용이 들어간다.
 

전략적 설계와 전술적 설계

앞으로 이 책에서는 다음의 내용들을 다룰 것이다.

• 전략적 설계

• 바운디드 컨텍스트로 도메인 모델을 분리하고 보편언어를 개발하는 방법
• 서브 도메인이 어떻게 시스템의 복잡성을 다룰 수 있게 도와주는지
• 컨텍스트 매핑을 통해 여러 개의 바운디드 컨텍스트를 통합하는 방법

• 전술적 설계

• 엔티티와 값 객체를 알맞은 크기로 묶는 애그리게잇 패턴
• 도메인 이벤트의 사용

---

Chap2. 바운디드 컨텍스트 및 보편언어와 전략적 설계

DDD 는 주로 바운디드 컨텍스트 내에서 보편언어를 모델링하는 것이다.
 

바운디드 컨텍스트 (Bounded Context)

바운디드 컨텍스트는 의미적으로 동일한 컨텍스트의 범위를 표현한다.
이 범위 안에 속한 컴포넌트들은 해당 컨텍스트에 특화되어 있다.
바운디드 컨텍스트는 모델이 구현되는 곳이고, 각 바운디드 컨텍스트마다 분리된 산출물이 나온다.
* 바운디드 컨텍스트가 조직의 핵심 전략적 계획으로 개발되고 있을 때, 이를 핵심 도메인이라고 한다.
* 바운디드 컨텍스트는 단일 팀에만 할당돼야 하고, 각 바운디드 컨텍스트마다 독립적인 소스 코드 리포지토리가 있어야 한다.
 

보편언어 (Ubiquitous Language)

바운디드 컨텍스트 안에서 일하는 팀이 모델을 생성하고, 모델은 팀 구성원의 언어를 반영한다.
따라서 보편언어를 사용하면 팀 구성원 모두가 그 표현의 의미를 정확히 이해한다.
동시에 바운디드 컨텍스트는 마치 언어의 경계와 같기 때문에, 
서로 다른 바운디드 컨텍스트는 동일한 용어에 다른 의미를 부여할 수도 있다.
따라서 컨텍스트 밖의 어떤 컴포넌트도 컨텍스트 안의 것과 같은지 알 수 없다.

 

바운디드 컨텍스트의 필요성

소프트웨어 설계를 하다보면 흔히, 우리는 떠오르는 개념들을 계속해서 이어붙여나간다.
이렇게 너무 많은 개념들을 한번에 다루려고 하다보면, 다수의 언어가 혼재하게 되고 각각의 의미가 모호해지기 시작한다.
동시에 핵심 개념으로부터 멀어지게 되고, 하나의 거대하고 혼란스러운 덩어리가 탄생한다.
이것을 진흙 덩어리 (big ball of mud) 라고 표현한다. 엉망잔칭이라는 소리다.
우리는 이렇게 진흙 덩어리가 되는 것을 막기 위해서 바운디드 컨텍스트를 나누기로 한다.
우리는 서로 다른 개념들을 각각 다른 바운디드 컨텍스트로 분리해야 할 것이다.
바운디드 컨텍스트는 핵심이 되는 개념들을 밀접하게 유지하며 포함해야 하고, 그 외는 모두 제외시켜야 한다.
이렇게 핵심만 걸러내어 정의된 개념들은 이 바운디드 컨텍스트의 보편언어가 된다.

핵심이 무엇인가?

핵심이 무엇인지 알기 위해서는 도메인 전문가와 개발자가 협업해야 한다.

도메인 전문가는 당연히 비즈니스 문제에 집중한다.

보편언어의 토대는 비즈니스를 바탕으로 한 도메인 전문가들의 멘탈 모델이다.

개발자는 소프트웨어 언어와 기술에 빠지지 않도록 주의하고, 비즈니스 초점을 받아들여야 한다.

 

사례 연구

스크럼 기반 애자일 프로젝트 관리 어플리케이션을 설계하는 과정을 사례로 들어본다.
아래 그림은 이 어플리케이션을 설계하는 과정에서 너무 많은 개념을 이어붙이다가 결국 진흙 덩어리가 되어버린 모습이다.

그리고 아래는 바운디드 컨텍스트로 도메인 모델들을 분리한 모습이다.

- 핵심 도메인과 핵심이 아닌 다른 도메인을 분리했다.
- Discussion 은 핵심 모델의 일부인 동시에 이것을 지원하는 부수적인 컴포넌트들이 필요하다. 
따라서 다른 바운디드 컨텍스트와의 협업을 통해 적절하게 동작할 것이다. (협업 컨텍스트)
- 핵심 도메인에서 제외된 개념들은 다른 바운디드 컨텍스트에 정의될 것이고, 컨텍스트 매핑을 통해 통합될 것이다.
 

보편언어를 개발하는 방법

꼭 명사여야만 할까? 아니다. 우리는 명사보다 더 많은 말을 사용한다.
핵심 도메인은 도메인 모델의 개념에 대한 구체적인 시나리오들을 나타낼 수 있어야 한다.
시나리오는 도메인 모델이 어떻게 동작해야 하는지, 어떤 컴포넌트가 동작하는지에 대한 것이다.
그리고 작성된 시나리오로 도메인 모델이 명세를 준수하고 있는지 검증해보자.
* 사례를 통한 명세, 행위 주도 개발 BDD (Behavior Driven Development)
→ 행위 주도 개발은 TDD 에서 파생된 개발 방법론이며 시스템이 어떻게 동작해야 하는지에 초점을 맞춘다.
기본 패턴은 Given-When-Then 이다. 
Given 은 시나리오 진행에 필요한 값, When 은 시나리오 진행에 필요한 조건, Then 은 완료 시 보장해야 햐는 결과를 명시한다.
* 인수 테스트를 만들어 보면서 이를 수행할 수 있다. (참고로 인수 테스트 주도 개발도 있다. ATDD)
그렇다면 보편언어를 개발하고 난 뒤에, 보편언어를 어떻게 관리해야 할까?
보편언어는 유지단계일 수 없으며 지속적으로 성장해야 한다.
핵심 목표에 지속적으로 기여해야 하며, 그렇지 않을 경우 정말 이 모델이 핵심 도메인일지 의심해봐야 한다.
 

아키텍처

* 도메인 모델은 기술로부터 자유로워야 한다.
포트와 어댑터 아키텍처가 DDD 와 함께 사용할 수 있는 유일한 아키텍처는 아니다.
필요에 따라 다른 아키텍처를 사용할 수 있다.
마이크로서비스는 DDD의 바운디드 컨텍스트보다 훨씬 더 작을 수 있다.
즉 여러 개의 마이크로서비스는 같은 논리적 바운디드 컨텍스트에 속할 수 있다.