이 글에서는 내가 지금까지 서적, 외부 강의, 그리고 경험을 통해 이해한 DDD와 이를 실제로 어떻게 적용했는지 공유하고자 한다.
도메인
우선 DDD를 이해하기 전에, DDD의 핵심인 '도메인'이 무엇인지 먼저 알아두면 좋다.
도메인은 특정 비즈니스 또는 우리가 해결해야 할 문제 영역을 의미한다.
예를 들어, 이커머스에서는 '주문', '결제', '상품' 등이 각각 하나의 도메인으로 정의될 수 있다.
위 예시는 간단했지만, DDD에서 말하는 도메인은 더 세부적으로 나타낼 수 있다.
핵심 하위 도메인
예를 들어, 쿠팡은 다음날 상품을 받을 수 있는 🚀 로켓 배송 서비스를 통해 다른 이커머스와 차별화를 두고 있다.
이러한 차별화된 서비스가 바로 핵심 하위 도메인에 해당한다.
이렇게 경쟁 업체와 다르게 수행하고 있는 것을 의미한다.
일반 하위 도메인
모든 회사가 같은 방식으로 수행하는 비즈니스 활동을 의미한다.
주로 이미 실무에서 검증된 방법으로 널리 이용하게 된다.
다시 말해 사내 솔루션으로 새롭게 처음부터 개발하는 것 보다는 기존 솔루션을 사용하는 것이 효과적일 수 있다는 의미이다.
예를 들어, 카드 결제 기능을 처음부터 새롭게 개발하기보다는, 토스페이먼츠와 같은 이미 검증된 결제 솔루션을 활용하는 것이 더 효율적이다.
지원 하위 도메인
핵심 하위 도메인, 일반 하위 도메인을 지원하는 보조적인 기능을 한다.
기본적인 ETL이나 CRUD 같은 인터페이스, 입력의 유효성 검증 등을 수행한다.
스프링부트 프레임워크나 외부 연동 같이 사내에서 해결해야 하면서도 누구나 개발할 수 있는 것들로 예시로 들어볼 수 있을 것 같다.
이렇게 도메인에 대한 범주 분석이 끝났다고 해서, 도메인이 고정될까?
정답은 그렇지 않다.
핵심 하위 도메인은 비즈니스 요구사항이 변화함에 따라 자주 개선되고 변경될 수 있다. 이는 경쟁 우위를 확보하기 위한 중요한 요소이기 때문에, 시장 변화나 고객 요구에 맞춰 유연하게 대응해야 하는 경우가 많다.
또한, 일반 하위 도메인의 규모가 커지거나 중요성이 증가하면, 그 도메인이 핵심 하위 도메인으로 자리 잡을 수 있다. 반대로, 시간이 지나 핵심 하위 도메인이 더 이상 경쟁 우위를 제공하지 않는다고 판단되면 일반 하위 도메인으로 정의될 수 있다.
유비쿼터스 언어와 바운디드 컨텍스트
비즈니스를 실현하기 위해 개발자, PM, 기획자, 마케터 등 다양한 이해관계자가 함께 협업하게 된다.
그런데 각자가 서로 다른 방식으로 이해하고 있는 언어를 사용한다면 어떻게 될까?
운이 좋으면 같은 방향으로 이야기가 흘러갈 수 있지만, 운이 나쁘다면 각자가 전혀 다른 얘기를 하다가 마지막 결과물에서 큰 차이가 있음을 깨닫게 될 것이다.
이런 문제를 해결하는 가장 쉬운 방법 중 하나는 공통된 용어집을 만들어 관리하는 것이다.
이로서 유비쿼터스 언어를 현실적으로 실현할 수 있게 된다.
그러나 유비쿼터스 언어가 항상 모든 상황에서 같은 의미를 가지는 것은 아니다. 바운디드 컨텍스트에 따라, 같은 용어라도 다른 의미를 가질 수 있다. 예를 들어, '우유'라는 단어를 각기 다른 바운디드 컨텍스트에서 어떻게 해석하는지 생각해보자.
- 식료품 바운디드 컨텍스트: 이 컨텍스트에서 "우유"는 단순히 재고 관리의 대상인 제품이나 유제품 중 하나로 취급된다. 여기서 중요한 것은 우유의 종류, 유통기한, 가격 등이다.
- 요리 바운디드 컨텍스트: 이 컨텍스트에서는 "우유"가 요리의 재료 또는 레시피의 일부로 사용된다. 따라서 이 경우에는 우유의 성분, 요리에서의 사용 방법, 그리고 요리에서 차지하는 역할이 더 중요한 요소가 된다.
이처럼 유비쿼터스 언어는 협업자들이 서로 다른 의미로 받아들이지 않도록 바운디드 컨텍스트 내에서 일관성 있게 정의되어야 한다.
바운디드 컨텍스트가 달라지면 같은 용어도 각 컨텍스트에 맞게 다르게 해석될 수 있고, 이를 이해하고 관리하는 것이 DDD에서 매우 중요하다.
약간 다른 얘기지만, 개발자는 BDD 스타일로 작성된 테스트 코드를 통해 비즈니스 로직을 명확하게 표현하여, 동료 개발자들 간에 프로세스를 쉽게 이해시키는 방법으로 사용할 수 있다.
DDD(Domain Driven Design)를 하는 이유
그래서 DDD는 왜 하는 것일까?
DDD는 도메인 분석을 통해 도출된 핵심 규칙과 구조를 코드에 직접 반영하기 위해 존재한다.
모든 이해관계자가 같은 관점, 같은 생각, 같은 언어로 소통하고, 이러한 커뮤니케이션이 코드에 잘 녹아들게 된다면, 큰 조직에서도 유지보수가 용이한 구조가 마련된다. 이로 인해 비즈니스 변화에 빠르게 대응할 수 있으며, 대규모 시스템에서 발생할 수 있는 큰 걸림돌을 없앨 수 있다.
참고
- DDD Start
- NextStep DDD 사실과 오해
- 도메인 주도 설계 첫걸음
