도메인 주도 설계의 창시자는 Eric Evans이다. 2003년에 Domain-Driven Design:Tackling Complexity in the Heart of Software 책이 나옴으로써 시작되었다.
"객체 모델링을 어떻게 실제 소프트웨어 프로젝트에 적용할 것인지에 대해 미처 몰랐던 부분을 채워주고 시각 또한 향상시킬 것이다"
- Eric Evans(2003)
파트 1
- 모델 주도 설계: 도메인 모델을 설계와 구현으로 끌고 들어오는 것
- 도메인 모델과 설계 그리고 코드는 서로 영향을 주며 반복을 통해 구체화 된다. (도메인 모델은 그 자체로 코드이다)
- 유비쿼터스 언어 : 도메인 모델과 코드에 도메인 용어를 사용하는 것
- 도메인 전문가와 개발자가 동시에 사용할 수 있는 용어들을 코드에도 반영하자
- 지식탐구: 도메인 전문가들과 도메인에 대해서 깊이 있게 이해하고 요구사항을 반영하는 도메인 모델을 만드는 것
파트 2 : 모델 주도 설계의 빌딩 블록
- 구체적인 방법론이 나온다(실제로 개발자들과 관련자들이 가장 많이 언급하는 대목이다)
-
도메인 레이어에서 도메인을 표현하기 위한 방법론으로써 다음 두 가지가 있다. 빌딩 블록의 목적은 구현에 대한 가이드를 제공해서 복잡도를 낮추는 것이다.
- 도메인을 표현하기 위한 빌딩 블록: Entity , Value Object, Module, Service 등
- 생명주기를 관리하기 위한 빌딩 블록: Aggregate, Repositoty, Factory
-
불변식(invariant)을 중심으로 도메인 모델은 구현되어야 한다. 이 때 Aggregate는 불변식을 만족시키는 객체 그룹 단위 처리를 가능하게 한다.
-
Repository는 Aggregate단위와 연결될 수 있다.
-
Aggregate를 너무 복잡하게 만들지 않으려면 결과적 일관성(Eventual Consistency)를 유지하는 방식으로 작성되어도 된다. (message를 발행하게 하는 방식 등이 가능하다)
-
이러한 방법론은 자연스럽게 객체지향과도 잘 어울린다 (반드시 객체지향일 필요는 없다)
애자일과 도메인 주도 설계 (파트3 내용 중 일부만 정리)
도메인 주도 설계와 애자일일은 명시적으로 연결되어 있지 않지만 도메인 모델=코드로 정의한다면 이 순환을 지속적으로 가능하게 하는 것은 애자일 방법론과 가깝다. 또한 리팩터링과도 일맥상통하다.
파트 4: 전략적 설계
- 전체 시스템에서 도메인 모델이 하나일 필요는 없다. 전체 시스템 중에서 도메인 모델을 여러개로 분리해도 좋다. 그리고 분리된 도메인 중에서 일부에 집중하는 것이다.
- 같은 개념이라고 하더라도 다른 컨텍스트에 속하게 만드는 것이 때로 더 유용할 수 있으며 이를 Bounded Context라고 한다. 이는 특정한 도메인 모델이 적용되는 범위를 말한다.
- Presentation 부터 Persistence까지 수직 슬라이드를 포함한다(무슨 의미인지 아직 모르겠다)
- Bounded Context 사이의 관계를 Context Map이라고 한다. 직관적으로는 Bounded Context는 개발 팀 단위로 관리될 수도 있다.
- 전략적 Distilation을 통해서 가장 중요한 Context를 확인하고 집중할 수 있게 한다. 가장 중요한 서브도메인에 가장 뛰어난 인재를 투입하는 것도 집중의 한 방법이다.
마무리
주로 개발자들은 파트2: 모델 주도 설계의 빌딩 블록을 전술적 패턴이라고 부르며 여기에 집중하는 경향이 있다. 하지만 에릭 에반스는 파트3와 파트4에 좀 더 집중하려고 한 것 같다. 특히 파트3를 통해서는 리팩터링에 대한 개념을 도메인 주도 설계와 연결하려고 했고, 파트4를 통해서는 전략적 설계를 설명하려고 했다.
파트4의 14장. 모델의 무결성 유지는 솔루션 공간에 대한 해법을 15장. Distillation은 문제 공간에 대한 해법으로 이해할 수 있다. 워낙 개발자들이 관심을 끌지 못했던 것인지 Vaughn Vernon(2013)에서는 아예 전략적 패턴의 내용을 책 앞쪽으로 가지고 들어왔을 정도이다.
- 문제 공간: 각 서브도메인을 말한다.
- 솔루션 공간: 각 바운디드 컥텍스트를 의미한다.
알아두면 좋은 것들
- 이벤트 소싱: 도메인 이벤트를 스토어에 쌓아두었다가 이후에 재생하는 방식
- CQRS: 커맨드와 쿼리를 분리하는 방식
- MSA: 작은 서비스들간의 결합을 통해 하나의 응용 프로그램을 개발하는 방법으로 도메인 주도 설계에 다시 주목하게 된 계기가 됨
- Hexagonal Architecture: 사용자의 개입이나 데이터베이스가 사용될 수 없는 경우에도 자동으로 테스트 될 수 있는 구조
- 도메인 계층의 분리: 외부로 나가는 의존성이 존재하지 않아야 올바른 도메인 모델을 운영할 수 있다. 즉, 인프라 레이어나 비지니스 레이어(애플리케이션 레이어)로 로직이 새어나가지 않아야 한다.
(참고) Scott Millett(2015)는 C#을 가지고 설명하지만 매우 유용하다.
이미지 reference
1. https://dev.to/jhonifaber/domain-driven-designddd-understanding-main-concepts-11p3
2. https://ahmedhemaz.medium.com/my-journey-in-learning-domain-driven-design-part2-layers-and-hexagonal-architecture-67697ff1426c
