혹시 DDD 라는 용어를 들어보셨나요? DDD 는 도메인 주도 설계를 줄여서 DDD 라고 표현하는데 요즘 많은 곳에서 DDD 용어를 접할 수 있습니다. 요즘 도메인주도설계에 대해 관심이 많아졌는데 왜 많아졌으며, 도메인주도설계가 무엇인지 알아보려고합니다.
도메인 주도 설계가 왜 요즘 부각될까?
도메인 주도 설계는 2003년 에릭에반스의 “도메인 주도 설계” 책을 통해 등장하게 되었습니다. 나온지 오래된 용어인데 왜 최근에 부각받고 있을까요?
어떤분들은 MSA 로 인해 최근에 다시 DDD 가 떠오른다는 분들도 있습니다. 이 말도 맞는 말이지만 MSA 로 인해 DDD 가 떠오른다는 관점으로 봐라보면 DDD의 능력을 제대로 발휘하기 힘들 것 같습니다.
저는 도메인주도로 설계를 하다보면 자연스럽게 큰 문제를 해결하기 위해 고민하면서 작은 단위로 자르게 되고 작은 단위로 해결하기 위해 여러 문맥들로 나뉘다보니 자연스레 “MSA 구조와 궁합이 좋구나!” 하는 부가효과가 발생했다 생각합니다.
본질적으로 조금더 들어가면, 도메인 주도 설계가 부각된 이유를 좀더 확인하면 저는 기술의 발전때문이라고 생각합니다. 기술의 발전과 하드웨어 발전으로 인해 사업의 속도가 빨라지며 복잡한 문제들이 많아지고 있는데 요즘에 살아남기 위해서는 변화에 빠르게 대응이 필요하고 복잡한 문제를 다루기 위해 도메인주도설계가 부각받는 것이 아닐까 생각합니다.
도메인 주도 설계가 무엇이기에 복잡한 문제를 다루고 빠른 변화에 대응할 수 있을까?
모든 이해관계자가 문제를 해결하기 위해 다같이 모델링하고, 모든 이해관계자 관점에서 만들어진 도메인 모델이 소프트웨어로 살아숨쉬기 때문에 지속적인 변화에 빠른 대응이 가능하게 도와준다.
어떻게 복잡한 문제를 쉽게 다루고 빠른 변화에 대응할 수 있는지는 위의 문구 하나로 표현해볼 수 있을 것 같습니다. 그렇다면 도메인 주도 설계가 어떻게 위의 문장을 가능하게 하는지 살펴보겠습니다.
도메인주도설계에는 3가지 기둥이 있는데 다음과 같습니다.
- 유비쿼터스 언어
- 전략적 설계
- 전술적 설계
그럼 각각이 무엇을 의미하는지 알아보겠습니다.
유비쿼터스 언어란?
유비쿼터스 언어란 비즈니스 도메인과 관련된 팀 전체가 이해하고 사용하는 공통언어로, 단어를 들었을 때 모두가 동일한 것을 생각하도록 도와주는 언어입니다.
즉, 관련된 이해관계자가 모두 이해하고 동의를 얻은 언어이며, 이해관계자에는 개발자, 비개발자 모두 포함되어 있어 기술적인 용어보다는 비즈니스에 집중된 용어입니다.
그렇기 때문에 유비쿼터스를 사용하게 되면 공통된 이해와 효과적인 소통을 보장해줍니다.
전략적 설계란?
전략적 설계란 이해관계자들과 함께 문제를 해결하기 위해 도메인 모델을 만드는 것입니다. 전략적 설계에서 중요한 개념은 크게 다음과 같습니다.
- 바운디드 컨텍스트: 문제들을 해결하기 위한 영역(경계)으로, 하위 도메인마다 같은 용어라도 의미가 다르고 지칭하는 용어가 다르기에 각각의 경계안에서(바운디드 컨텍스트)에서 완전한 의미를 갖도록 합니다.
- 컨텍스트 맵: 여러 바운디드 컨텍스트 간의 고나계를 시각적으로 그려낸 지도로, 여러 컨텍스트의 관계를 명확히 합니다.
- 도메인 분류
- 핵심 도메인: 비즈니스 가치를 제공하는 핵심 도메인
- 지원 도메인: 핵심 도메인을 보조하는 도메인
- 일반 하위 도메인: 보편적이고 독립적인 도메인으로, 우리 비즈니스가 아니여도 어디서든 다 필요한 도메인
문제를 풀어나가기 위해서는 문제정의 또한 중요한데 대부분의 문제가 복잡하게 엮여있어 큰 문제인 경우가 많습니다. 그렇기에 복잡한 문제를 해결하기 위해 작은 문제로 쪼개고 쪼갠 문제를 해결하기 위해 도메인 모델을 만드는 과정을 통해 바운디드 컨텍스트를 찾을 수 있으며, 도메인을 핵심도메인과 지원도메인 그리고 일반 하위도메인으로 분류할 수 있도록 제공합니다.
전술적 설계란?
전술적 설계란 세부적인 설계 기법과 패턴을 사용해 바운디드 컨텍스트 내의 모데인 모델을 구체적으로 구축하고 구현하는 방법입니다. 전술적 설계에서 주요패턴은 다음과 같습니다.
- 엔티티
- 값객체
- 애그리거트
- 도메인서비스
- 팩토리
전략적 설계를 통해 생성한 도메인 모델을 그대로 소프트웨어로 구현하기 위한 패턴들의 모음집으로, 각각의 패턴들을 활용해 시스템 구축하는 것입니다.
그럼 다시, 위에서 설명한 한문장을 풀어서 이야기해보면,
(1) 모든 이해관계자가 문제를 해결하기 위해 다같이 모델링하고, (2) 모든 이해관계자 관점에서 만들어진 도메인 모델이 (3) 소프트웨어로 살아숨쉬기 때문에 지속적인 변화에 빠른 대응이 가능하게 도와준다.
모든 이해관계자들이 문제를 해결하기 위해 다같이 모델링을 하다보면 문제영역(하위도메인)들에 대해 알아갈 수 있고 명확해질 수 있습니다. 이 과정을 하다보면 문제와 문제들간의 경계가 명확해지며, 명확해진 해결영역(바운디드 컨텍스트)에서 문제영역(하위도메인)을 모두가 공감하는 언어로 단순화 혹은 추상화아여 도메인모델을 만들어 낼 수 있습니다.
유비쿼터스언어와 전략적 설계을 통해 문제를 해결하기 위한 개발자 관점이 아닌 모든 이해관계자 관점에서 만들어진 도메인 모델 을 시스템으로 구현하기 위해 전술적 설계에서 제공하는 다양한 패턴을 활용해서 살아숨쉬는 소프트웨어 가 되어 문제를 해결할 수 있어 도메인 주도 설계가 부각되는 것이라고 생각합니다.
즉, 결국 크고 복잡한 문제를 해결하기 위해 작은 문제(하위 도메인)으로 자르게 되고, 각각의 바운디드 컨텍스트(해결영역)에서 이해관계자 모두 공감하고 이해하는 모델링을 계속 고도화하고 고도화된 모델링을 코드화할 수 있어 지속적이고 빠른 사업 변화에 대해 대응하기 쉬워진다라고 생각합니다.