DDD 핵심 개념: 도메인과 모델, 그리고 우리가 나누는 언어

이 포스트는 에릭 에반스, ⌜도메인 주도 설계⌟를 읽고 작성하였습니다.

왜 이 책을 읽었는가?

이번에 새로 입사하고, 여러 웨비나를 보고, AI 에이전트를 써보고, 하네스 엔지니어링까지 해보면서 든 생각은 “설계가 더 중요해졌다”는 것이었다.
그래서 요즘은 소프트웨어 설계뿐만 아니라 요구사항 분석(BA), 그 밖의 소프트웨어 공학 전반에 대한 통찰을 얻고 싶어서 관련 도서들을 꽤 읽고 있다.
(그러다 보니 교보문고 플래티넘 등급을 달성해버렸다…)

그러던 중 하네스 파이프라인을 설계하다가 문득 DDD에 유독 낯설어하는 나 자신을 발견했고, 부랴부랴 이 책을 집어 들었다.

도메인과 모델은 다른 것이다

책을 읽으면서 가장 먼저 바로잡게 된 생각이 바로 도메인(Domain)과 모델(Model)을 구분하는 것이었다.
이 둘을 비슷한 개념으로 생각하고 있었는데, 명확히 다른 층위에 있는 개념이었다.

• 도메인(문제 공간, Problem Space): 소프트웨어가 해결하려는 현실의 비즈니스, 활동, 지식의 영역이다. 개발자가 코드를 짜기 이전부터 이미 현실에 독립적으로 존재하는, 변하지 않는 사실이다.
• 모델(해법 공간, Solution Space): 그 복잡한 도메인 중에서 문제 해결에 필요한 핵심 요소만 의도적으로 골라내어 단순화한 개념적 형태다.

누구와 이야기하느냐에 따라 언어가 달라져야 한다

책에서 인상 깊었던 부분은, 도메인과 모델 중 어떤 언어를 쓸지가 상대가 누구냐에 따라 달라져야 한다는 점이었다.

소통 대상	사용 언어의 중심	이유
사용자 / 클라이언트 / BA(도메인 전문가)	도메인	현실의 비즈니스 문제와 요구사항 그 자체에 집중해야 하므로, 유비쿼터스 언어를 바탕으로 소통한다.
내부 개발자(같은 도메인 지식을 공유할 때)	모델	시스템 내부의 추상화된 구조, 데이터, 행동을 논의하고 설계해야 하므로.
외부 개발자 / 타 파트(프론트, 3D 등)	도메인	내부 구조(모델)를 들이밀면 오해가 생기기 쉬우니, 모두가 공감할 수 있는 현실의 비즈니스 목적과 데이터 흐름으로 맥락을 맞춰야 한다.

여기서 눈에 띄는 건 ‘외부 개발자’와의 소통도 도메인 언어를 써야 한다는 점이었다.
나는 은연중에 ‘같은 개발자니까 모델 언어로 이야기해도 통하겠지’라고 생각해왔는데, 그게 착각이었다.

파트가 다르면 서로가 가진 모델 자체가 다르다.
내 모델을 상대에게 그대로 던지는 순간, 상대는 그걸 자기 모델로 재해석하려다 오해가 쌓인다.

다른 프로젝트에서 프론트엔드와 백엔드 개발자가 같은 기능을 두고도 관점 차이로 부딪히는 걸 본 적이 있는데, 지금 생각해보면 그것도 같은 이유였던 것 같다. 결국 서로 다른 모델을 가진 사람들끼리는 공통분모인 도메인으로 이야기해야 오해가 줄어드는 셈이다.

깨달은 것

이번 회사에서는 백엔드를 혼자 맡아서 개발하다 보니, 프론트엔드나 3D 그래픽스처럼 나와 다른 파트에서 일하는 팀원에게 뭔가를 설명할 때마다 유독 진이 빠졌다.
팀원이 풀스택 개발자라 백엔드에 대한 이해가 어느 정도 있을 거라 생각해서, 나는 테이블 구조나 상태 값, 함수 이름 같은 백엔드의 데이터 흐름을 기준으로 설명하곤 했다.
그런데 분명 같은 기능, 같은 요구사항을 두고 이야기하는데도 서로 개념이나 용어를 다르게 이해하고 있다는 느낌을 받은 적이 한두 번이 아니었다.

이 파트를 읽고서야 그게 소통이 어려웠던 근본 원인이었을 수도 있겠다는 생각이 들었다.
다음에 의견을 나누는 자리에서는 모델보다 도메인을 기반으로 먼저 설명해봐야겠다.