도메인 주도 설계란?
에릭 에반스의 DDD(Domain-Driven Design)에서 가장 기억하고 싶은 내용은 ‘하나의 팀에서 하나의 언어로’라는 부분이다. 개발(Development)을 끌고 가는 중심에는 해당 업무 즉, 도메인 프로그램 개발의 대상이 되는 업무 영역이 있다
여기서 말하는 도메인은 아래와 같다.
- 소프트웨어로 해결하고자 하는 문제 영역
- 사용자가 소프트웨어를 사용하는 대상 영역
- 소프트웨어는 도메인의 문제를 해결하는 수단임
- 일반적인 요구사항, 전문 용어, 그리고 컴퓨터 프로그래밍 분야에서 문제를 풀기위해 설계된 어떤 소프트웨어 프로그램에 대한 기능성을 정의하는 연구의 한 영역
서로 다른 말을 사용하는 고객과 개발자
개발자가 새로운 분야의 프로젝트를 만나면 도무지 알 수 없는 용어들을 접하게 된다. 특수성이 심한 업무는 고객의 업무 규정이나 보고서를 아무리 읽어도 해독이 불가능한 경우도 있다. 한 페이지의 절반가량을 차지하는 단어가 처음 보는 영문 약어로 기술되어 있는 문서를 상상해보라.
그럼 고객의 입장에서 생각해 보면 어떨까. 바쁜 시간에 불러내서 초보적인 질문에 답변을 해주고 있었다. 그러다가 앞으로 만들어질 프로그램에 궁금한 마음이 생겨, 개발자에게 물어보았더니 도무지 알아들을 수 없는 말만 한다.
이러한 어려움에도 불구하고 고객과 개발자가 잘 소통해야만 원하는 결과를 만들 수 있다. 반대로 이들이 서로 소통에 실패한다면, 원하는 결과는 나오지 않고 서로 잘못된 일만 반목하게 될 것이다.
에릭 에반스는 프로젝트 팀이 지향할 목표지점을 분명하게 도식화했다. 위 그림은 DDD 34쪽의 그림을 간략하게 요약한 것이다. Ubiquitous Language(이하 UL)는 고객과 개발자 양쪽에서 통용되는 어휘를 의미한다. 처음에는 교집합이 없이 나누어져 있다고 하더라도, 프로젝트를 진행하면서 교집합을 충분히 늘려가야 한다.
한편, 어떤 어휘의 경우는 공통의 어휘 구실을 하지 못할 수도 있다. 프로그램에 포함시킬 수 없는 업무의 어휘나 기술 자체에 대한 결정사항은 굳이 서로 논의하여 혼란을 야기할 필요는 없다.
결국 도메인 주도 설계는
모델이 그 가치를 잃지 않고 소프트웨어 개발에 기여하도록 도메인을 잘 표현한 모델을 만들고 함께 끝까지 그 모델을 바라보는 것이다.
그럴려면…
- 모든 사람이 모델 생성에 참여해야 한다.
(도메인 전문가, 분석가, 아키텍트, 개발자…) - 모델은 여러사람이 늘 검증해야 한다.
- 도메인 전문가가 이해할 수 있는가?
- 모르는 사람이 모델을 보면서 대상 도메인을 이해할 수 있는가?
- 모델이 구현 가능한가?
- 모든 사람이 모델에 나타나 있는 같은 언어(용어)를 사용해야 한다. (도메인의 용어를 그대로!)
- 해당 도메인의 정수(핵심)만이 표현돼야 합니다.