Domain Driven Design의 역사
Domain Driven Design의 탄생
소프트웨어가 점점 복잡해지면서 공학자들과 아키텍트들은 시스템의 구조에 대해 여러 가지 고민을 하였고, 모델링하려는 문제 공간(도메인)을 시스템에 나타내는 방식으로 접근했다. 이 때 시스템이 도메인에 가까울 수록 변경하기가 쉽다는 장점이 있었고, 시스템과 실세계의 도메인 사이의 단절이 적기 때문에 다른 관계자가 모델을 이해하기 쉬웠다.
소프트웨어 엔지니어인 Eric Evans가 마주한 문제는 시스템의 복잡성 증가와 시스템 생성 및 유지 보수의 실패였다. 이로 인해 그는 Domain-Driven Design: Tacking Complexity in the Heart of Software , Addison-Wesley Professional 이라는 책을 저술하였다.
이 책은 복잡한 시스템을 구축하고 유지하는 데 도움이 되는 방법들을 제시하며, 도메인 주도 설계의 많은 부분이 객체지향 설계 패턴에서 유래했음을 언급하고 있다.
객체지향 패턴이란?
1995년도에 저술된 Design Patterns, Elements of Reusable Object-Oriented Software라는 책은 현재까지도 컴퓨터공학 분야에서 가장 유명한 책 중 하나이다. 이 책에서는 뛰어난 확장성과 유지보수성을 가진 객체지향 소프트웨어를 설계하기 위한 23개의 패턴을 소개하고 있다. 그리고, DDD에서도 이러한 패턴 중 일부에서 아주 중요한 영감을 얻었다고 한다.
- Creational Patterns : 오브젝트를 직접 생성하지 않고, 생성하는 방법을 제공하는 패턴으로, 오브젝트 생성의 유연성을 높이고 코드의 유지보수를 쉽게 한다.
- Structural Patterns : 특정 기능을 수행하기 위해 클래스와 객체를 조합하는 패턴으로, 클래스와 객체의 구성을 통해 더 큰 구조를 만들 수 있다.
- Behavioral Patterns : 오브젝트 사이의 통신에 관한 패턴이다.
Big Blue Book이라고도 불리는 Evans의 책은, 세련되고 명확한 시스템을 설계하기 위한 공통 언어와 원칙을 제시한다. 또한, 복잡한 소프트웨어를 개선할 때 사용할 수 있는 세 가지 기둥을 제시한다.
DDD의 세 가지 기둥
Ubiquitous Language
도메인에대해 이야기할 때 사용하는 공통 언어이다. 이 언어는 도메인 전문가와 개발자 모두가 사용할 수 있어야 하며, 소통 과정에서의 불확실성을 줄여 준다.실제 언어와 마찬가지로, 유비쿼터스 언어는 도메인에 대한 팀의 이해가 높아질수록 발전해야 한다. 비즈니스 언어가 아니기 때문에 도메인 전문가에 의해 강요되어서는 안 된다.
Strategic Design
비즈니스 도메인을 매핑하고 제한된 컨텍스트를 정의하는 DDD 프로세스의 한 단계이다. Strategic Design의 목표는 비즈니스 결과에 초점을 맞춰 시스템을 설계하는 것이다.먼저 문제 공간의 추상적 표현인 도메인 모델을 만든다. 제한된 컨텍스트를 만들기 위해 이 단계에서 해야 할 일이 더 있지만, DDD 프로세스의 초기 단계에서도 시스템이 어떻게 보일 지 생각할 수도 있다.
Tactical Design
Tactical Design에서는 시스템이 어떻게 보일지에 대한 세부사항을 다룬다. 이 단계에서는 entity, aggregates, 그리고 value object에 대해 논하며, 이러한 패턴을 통해 소프트웨어 경계를 정의한다.
Adoptation of DDD
DDD는 그 개념이 처음 등장했을 때부터, 지금까지도 매우 인기있는 개념이다. Microsoft나 Amazon 같은 기업에서도 내부적으로 DDD를 사용하므로, DDD를 배우는 것은 가치있는 일이라고 할 수 있다.
물론 DDD를 어느 곳에사 사용할 수 있는 것은 아니다. 여러 대기업에서 사용하긴 하지만, 모든 사이드 프로젝트에 적합하지는 않다. 다음 장에서 이에 대해 자세히 살펴보자.
언제 DDD를 사용해야 할까?
DDD는 크고 복잡한 시스템에 더 적합하다. 절대다수의 소프트웨어 개발자들이 작성하는 소프트웨어는 기본적인 CRUD 애플리케이션이다. 이러한 애플리케이션에 DDD를 적용하는 것은 오히려 더 복잡하고 비효율적일 수 있다.
Big Red Book에서는 다음과 같은 DDD 스코어 카드를 제시한다.
| 프로젝트 종류 | 포인트 | 고려할 사항 |
|---|---|---|
| 주로 DB에서 단순한 CRUD 작업만을 하는가? | 0 | ‘단순하다’는 평가를 내리는 게 쉽지 않긴 하지만, 입력과 출력 사이에 많은 비즈니스 로직이 있는 경우 이 범주에 맞지 않을 수 있다. 반면, 입력을 Validating하여 데이터베이스 레이어로 전달하는 것 뿐이라면 이 범주에 속한다. |
| 애플리케이션이 30개 미만의 유저 스토리 및 비즈니스 플로우를 가지는가? | 1 | 만약 미래에도 이러한 유저 스토리가 추가되지 않고 자잘한 마이너 업데이트만 계획되어 있다면, DDD를 적용할 필요성이 높지 않은 셈이다. |
| 애플리케이션이 40개 이상의 유저 스토리 및 비즈니스 플로우를 가지는가? | 2 | 이 단계에서부터는 DDD를 도입하는 것을 적극적으로 고려해볼만 하다. 복잡한 시스템을 구축하고 있는 것 같다면, 미리 DDD를 도입하는 것이 좋을 수도 있다. |
| 애플리케이션이 점차 복잡해질 가능성이 있는가? | 3 | 어떤 애플리케이션은 간단하게 시작하지만, 복잡도가 증가하기도 한다. 예를 들어 스타트업에서는 처음 몇 달 동안은 간단한 일만 할 수 있지만, 투자를 받고 나면 해결하려는 문제의 복잡성을 강화해야 한다 |
| 애플리케이션이 오래동안 유지될 것이며, 변경 사항은 간단하지 않을 것으로 예상된다. | 4 | 정기적인 변경을 거치지 않는 프로그램은 거의 없다. DDD가 적합한지 판단하기 위해, 필요한 변경 사항의 복잡도를 이해하는 것은 중요한 일이다. 간단한 변경 사항보다는 크고 복잡한 변경 사항이 이 카테고리에 보다 적합하다고 볼 수 있다. |
| 현재 도메인이 새롭기 때문에 잘 이해하지 못한 상태이며, 내가 아는 한 이러한 종류의 시스템을 구축해본 사람이 없다. | 5 | 모델링과 도메인 정의는 DDD의 빵과 버터와 같다 |
만약 테이블에서 7 포인트 이상을 획득했다면, DDD를 적용하는 것이 좋다고 볼 수 있다. 반면 7 포인트 미만이라면, DDD의 일부 원칙이 도움이 될 수는 있지만 제대로 된 DDD를 적용하는 것은 비효율적일 수 있다.
References
[
[Matthew Boyle, Domain-Driven Design with Golang』, O'Reilly Media, Inc.](https://learning.oreilly.com/library/view/domain-driven-design-with/9781804613450/)