[DDD] 서브도메인 구분하기

Aryumka·2024년 6월 2일
post-thumbnail

블라드 코노노프의 "도메인 주도 설계 첫걸음"으로 진행된 DDD 스터디에 참여하며 첫 주에 나누었던 내용을 책과 연관지어 정리해보려 한다.

Why DDD(Domain Driven Design)?

소프트웨어 개발의 핵심은 문제 해결이다.
DDD도 마찬가지이다. 비즈니스, 즉 도메인의 문제를 소프트웨어로 해결할 때 이 문제가 어떤 문맥에서 존재하는지를 먼저 이해해야 한다.

Q) DDD를 잘하면 비즈니스가 잘될까?
A) No. 비즈니스 문제는 너무나 방대하다. 잘 만든 제품이 모든 먹고 사는 문제를 해결해주진 않는다. DDD는 비즈니스 문제 중 소프트웨어로 해결 가능한 문제를 우아하고 효율적으로 해결하고자 하는 개발 방법론에 가깝다.

도메인

도메인, 즉 비즈니스 도메인은 회사의 비즈니스 활동 영역이며 문제 해결 영역이다. 하나의 회사는 여러개의 비즈니스 도메인을 가질 수 있다. 아마존의 쇼핑몰과 클라우드 컴퓨팅 서비스는 별도의 비즈니스 도메인이다. 회사가 어떤 것으로 돈을 벌지에 따라 비즈니스 도메인은 언제나 변경 대상이다.

서브도메인

서브도메인은 도메인의 구성요소(Building Block)이며 비즈니스 활동의 세부적인 영역이다. 서브도메인이 서로 협력하여 비즈니스 활동의 목표를 이룰 수 있도록 돕는다.

서브 도메인은 핵심 서브도메인(Core Subdomains), 일반 서브도메인(Generic Subdomains), 지원 서브도메인(Supporting Subdomains)의 세 가지로 나뉜다.

핵심 서브도메인

  • 핵심 서브도메인은 경쟁자들과 다르게 만드는 부분이다. 새로운 기능 개발이나 비용 절감 등의 최적화가 모두 여기에 해당된다.
  • 복잡성이 높다. 핵심 비즈니스 규칙, 복잡한 알고리즘 등이 담겨있다.
  • 변동성이 높다. 끊임없이 발전하기 때문이다.
  • 내부에서 자체 개발해야 한다.
  • 경쟁자들에 비해 차별화되어야 하는 영역이지만 반드시 기술적인 영역은 아니다. 독창적이고 심미적인 디자인, 전문가들의 인력 등 기술 이외의 다양한 분야가 핵심 서브도메인이 될 수 있다.

일반 서브도메인

  • 일반 서브도메인은 경쟁자들과 별 다르지 않게 만드는 부분이다.
  • 비즈니스 영역보다는 일반적인 문제를 해결한다. ex) 인증, 권한, 암호화
  • 핵심 서브도메인만큼이나 복잡하고 구현이 어려울 수 있지만 이미 만들어진 솔루션으로 대체해도 큰 문제가 없는 영역이다. 온라인 보석 판매 업체에게는 온라인 쇼핑몰 자체가 일반 서브도메인이며 보석 디자인이 핵심 서브도메인이 된다.

지원 서브도메인

  • 비즈니스 영역을 지원하는 영역이다.
  • 하지만 핵심 서브도메인과는 다르게 경쟁우위를 제공하지는 않는다.
  • 비즈니스 영역을 잘 지원할 수 있도록 자체 개발하는 것이 좋다. 외주를 써도 좋다.
  • 복잡하지 않은 CRUD 등의 단순한 기능이 주를 이룬다. 해결되었든 아니든 해결방법이 명확한 기능이다.

서브도메인을 어떻게 구분할 것인가?

위의 구분에도 불구, 하위도메인 구분짓기는 어려운 일이다. 서브도메인을 구분하기 위해 책에서는 다음과 같은 가이드라인도 제시한다.

  • 사이드 비즈니스가 될 수 있는가? 누군가 여기에만 돈을 낼 용의가 있는가? → 핵심 서브도메인
  • 이미 존재하는 기능을 사오는 것보다 직접 만드는 게 싼가? → 지원 서브도메인
  • 해당 기능을 구현하기 위해 디자인패턴, 복잡한 알고리즘 사용 등 기술적 복잡도가 올라가는가? → 핵심 서브도메인

스터디 내에서도 서브도메인 구분하기는 많은 논의의 대상이었다. 도메인 자체도 변화의 대상이지만 동일한 도메인의 다른 생명주기에서 서브도메인 타입이 고정되어 있지 않으므로 더욱 혼란스러웠다.
(비즈니스와 마찬가지로 서브도메인은 진화한다. 일반 서브도메인이 핵심 서브도메인이 되기도 하고 핵심 서브도메인이 일반 서브도메인이 되기도 한다. 이 내용은 11장에 자세히 나와있다고 한다.)

책에서는 모든 서브도메인이 명확하게 구분될 필요는 없지만 핵심 서브도메인 만큼은 반드시 명확한 구분이 필요하다고 했다.

비즈니스와 밀접하게 연관되기 때문에 자연스럽게 수익성 측면에 초점이 맞춰지지만 책에 따르면 핵심 서브도메인은 반드시 경쟁우위, 복잡성, 변동성을 동반해야 한다.

구분은 여전히 쉽지 않지만 토론 중에 나온 이야기들을 조금씩 바꿔 내 생각을 정리해봤다.

Q. 지원 서브도메인의 간단한 기능도 회사에 수익을 가져다 줄 수 있지 않나? 그렇다면 핵심 서브도메인과 무엇이 다른가?
A. 여기서 말하는 비즈니스에서의 "경쟁" 우위라는 것은 비즈니스에서 진입장벽을 의미한다. 간단하게 따라할 수 있는 핵심 서브도메인의 수명주기는 짧다. 경쟁자들에 의해 결국 이익이 0에 수렴하게 되기 때문이다. 돈이 벌리는지 여부보다 일반적인 시장 논리에 초점을 맞춰야 한다.
즉 필연적으로 쉽게 따라할 수 없는 복잡한 영역이어야 핵심 서브도메인이 될 수 있다.

Q. 은행의 전산 시스템은 늘 외주로 개발된다. 입출금 등 전산 시스템은 은행의 핵심 비즈니스인데 왜 외주로 개발할까?
A. 핵심 서브도메인은 경쟁 우위를 만들어낼 수 있는 영역이다. 한 은행의 전산시스템을 최적화하여 다른 은행으로부터 경쟁우위를 만들어낼 수 있을까? 만약 없다면 이건 이미 해결된 문제로 일반/지원 서브도메인의 영역에 가깝다. 전산시스템보다는 은행의 상품이나 금리가 핵심 서브도메인에 더 가까울 수 있다.

마무리

DDD를 어떻게 유용하게 써먹을 수 있을까?
단순히 우아한 설계나 클린한 코드를 썼다는 개발자의 자기 만족의 영역에만 머무르고 싶진 않다.


우아한 코드 그런 순수한 인간적인 감정으로다가 접근하기보단 자본적인 개념으로다가 나가야 한다.

핵심 서브도메인은 외부의 요인에 의해서 변하는 것만은 아니다.
고객의 불편을 적극적으로 찾아내고 해결함으로써 핵심 서브도메인이 바뀔 수 있다. 공급은 수요를 창출하기도 한다.

소프트웨어가 해결할 수 있는 고객의 문제는 아직도 무궁무진하다고 믿는다.
다만 발견되어지길 기다리고 있을 뿐.

아직 스터디 1주차지만 일단 책 내용이 구체적이라서 좋았다. 또 혼자라면 생각하지 못했을 부분들을 다들 말씀해주셔서 많이 배울 수 있었다. DDD를 써먹을 수 있는 방법들을 더 공부해나갈 생각에 많이 설렌다.

profile
아륨까라고 읽습니다.

0개의 댓글