도메인 주도 설계 - DDD란 무엇일까요?

 

개발쪽에서 어느정도 일을 하신 분이라면 도메인 주도 설계라는 용어를 접해 보셨을겁니다. 도메인 주도 설계란 도대체 무엇이고, 어떻게 적용할 수 있을까요? 

도메인 주도 설계라는 단어만 놓고 보면 무언가 그럴듯한 개발 방법론이나 스킬을 잔뜩 포함하고 있을 것 같은 느낌이 듭니다. 저도 처음에 도메인 주도 설계라는 용어를 접했을 때 이것을 공부하면 나의 개발 스킬을 한단계 업그레이드 시킬 수 있지 않을까라고 생각했습니다. 책을 구입하여 읽기 시작했지만, 처음 몇 챕터를 읽었는데도 개발 얘기는 나오지 않고 우리에게 주어진 환경과 같은 얘기만 계속 나와 실망을 하긴 했습니다. 몇 챕터를 지나니 개발에 관련된 스킬 및 택틱들이 나오기 시작하더군요.

사실 도메인 주도 설계라는 것은 개발과 관련된 기술보다는 비즈니스적 정의에 가깝다고 생각합니다. 이 비즈니스적 정의를 실현하기 위해 다양한 기술들이 소개되는 것이라고 봐도 무방할 것 같습니다. 여러분들이 정의할 수 있는 도메인 주도 설계란 무엇을까요? 이미 많은 책들에서 기술되어 있지만 저는 이렇게 정의하고 싶습니다.

 

도메인 전문가와 유비쿼터스 언어로 협의하며 반복적인 주기를 통해 개발을 진행하는 프로세스.

 

도메인 전문가란 무엇일까요? 어떤 업무에 대한 지식이 빠삭한 사람을 도메인 전문가라고 칭할 수 있습니다. 어느 기업의 인사팀에서 급여를 관리하는 사람이 있습니다. 이 사람은 급여 관리에 관한 프로세스 및 업무 전문가라고 할 수 있습니다. 이 사람이 영업팀과 관련된 프로세스를 잘 알지도 못하고, 그 쪽 업무와 관련된 일을 할 일도 없을 겁니다. 그렇다면, 우리가 급여 관리 시스템을 개발한다면 이 도메인 전문가에게서 지속적으로 업무 프로세스에 대한 설명을 듣고 그가 요구하는 시스템을 개발하게 될 겁니다. 

하지만 도메인 전문가의 지식이란 그가 속해 있는 기업의 크기와 관련이 있습니다. 위의 도메인 전문가는 직원이 2000명이 넘는 대기업의 담당자라 그쪽 업무만 담당하겠지만, 만약 직원수가 10명 미만인 작은 회사이고 한명이 모든 인사 업무를 관리한다면 어떨까요? 그 한 명이 그 회사의 모든 도메인 지식을 가지고 있는 사람이 될 것 입니다. 중요한 것은 그 시스템을 만드는데 필요한 해박한 지식을 가진 전문가와 소통을 하면서 개발을 해야지 그렇지 않다면 당연히 그 프로젝트는 산으로 가게 될 겁니다.

유비쿼터스 언어란 도메인 전문가와 개발팀 사이에 공통으로 통용되는 업무 관련 용어 정의라고 할 수 있습니다. 우리가 일상적으로 쓰이는 용어가 각 도메인에서는 다르게 사용되는 경우들이 있거나 의미가 모호한 경우가 많습니다. "사용자"라는 단어가 개발 분석 시 자주 사용됩니다. 하지만 "사용자"라는 단어는 다의적인 단어 입니다. 급여 담당자가 사용자라는 단어를 사용할 때는 "인사팀에서 급여 관리에 접근할 수 있는 사용자"라고 생각을 하나, 분석팀에서는 기업 내의 모든 사용자라고 해석할 수도 있는 것이죠. 이러한 의미가 모호하거나, 그쪽 도메인에서만 사용되어 개발 분석가가 이해하지 못하는 단어들에 대해 서로의 합의를 통해 이 단어는 무엇을 의미한다라고 정의하는 것이죠. 일종의 Term의 구체화라고 할 수 있습니다.

반복적인 주기는 필수적인 요건은 아니지만 최근 대부분의 개발 프로세스는 에자일 방법론을 사용하므로 반복적인 주기를 포함시켰습니다. 폭포수 모형으로도 개발이 가능하지만 이미 효율적인 방법론이 아니라는 것은 명확해졌기에, 비즈니스 분석 후 짧은 기간에 프로토타입을 만들어 담당자에게 확인을 받은 후 지속적으로 개선해 나가는 프로세스가 효율적이기 때문입니다.

다음에는 Bounded Context에 대해 얘기해보도록 하겠습니다.