Introduction
이번 장에서는 도메인 주도 설계(Domain Driven Design)에 대해서 알아보겠습니다. 이것이 왜 중요한지는 Domain Driven Design의 저자 Eric Evans의 말로 충분할 것 같습니다.
Eric Evans, Domain-Driven Design
개발자들이 도메인에 대한 통찰을 얻기 위해 적용할 수 있는 체계적인 사고 방법이 존재한다. 무질서하게 뻗어 나가는 소프트웨어 애플리케이션에 질서를 부여할 수 있는 설계 기법 역시 존재한다. 이런 기술을 연마한다면 익숙하지 않은 도메인을 접하게 될 경우에도 더 가치 있는 개발자로 발전할 수 있게 될 것이다.
Domain
도메인 주도 설계에 대해 알기 위해서는 먼저 도메인에 대해서 알아야합니다. 도메인의 사전적 의미는 "정보와 활동의 영역"을 말하며, 흔히 프로그래머들에게는 애플리케이션 내의 로직들이 관여하는 정보와 활동의 영역 이라고 받아들여집니다.
예를들어, 어떤 웹 서비스를 만들 때 회원을 가입하고, 회원을 탈퇴하는 일련의 작업은 "회원"과 관련된 일련의 작업들이며 여기서 "회원"이라는 도메인이 있다고 볼 수 있습니다.
DDD (Domain Driven Design)
도메인 주도 설계란 개발을 함에 있어 위에서 설명한 도메인이 중심이 되는 개발 방식을 말하며, 그 목적은 소프트웨어의 연관된 부분들을 연결하여 계속해서 진화하는 새로운 모델을 만들어나가 복잡한 애플리케이션을 만드는 것을 쉽게 해주는 것에 있습니다. DDD의 핵심적인 목표는 도메인 간 느슨한 결합도(Loose Coupling)와 도메인의 높은 응집도(High Cohesion)로 가벼운 설계를 위해 탄생하였습니다.
결국 도메인 내의 여러 업무 정의나 문제를 어떻게 모델로 표현하고 그것을 바탕으로 구현하기 쉽게 이해할 수 있는 구조로 정의되냐가 DDD의 핵심입니다. 따라서 도메인 모델 설계시 아래의 3가지 요구사항을 충족시켜야 합니다.
1.
모델과 핵심 설계는 상호 영향을 주고 받으며 구체화된다.
2.
모델은 모든 팀 구성원들이 사용하는 언어의 근간을 이룬다.
3.
모델은 불순물을 걸러낸 핵심 지식만을 포함한다.
Ubiquitous Language (보편 언어)
도메인 주도 개발은 Eric Evans가 2003년 출간한 책에서 처음 소개한 방법론으로 "유용한 소프트웨어를 개발하고 싶다면 도메인에 귀를 기울여라"라는 슬로건으로부터 시작됩니다.
도메인 전문가와 개발자 사이의 의사소통의 어려움은 도메인 컨셉의 Ubiquitous Language 라는 보편적 언어로 표현하는 것을 목표로 합니다.
도메인 모델은 이러한 **보편 언어(Ubiquitous Language)**의 근간을 제공하고 팀 내의 의사소통 및 구현까지 연결할 수 있도록 하고 있습니다. 즉, 사용되는 언어에 대한 이해가 서로 일치해야 하며, 그렇지 않은 경우 모델 변경 및 코드상으로는 Refactoring으로 이어지는 과정이 나타납니다.
그리고 보편 언어들로 정의할 때 고려되어야할 사항은 Bounded Context(제한 영역) 범위 내에서 정의해야 된다는 것입니다.
Bounded Context는 독립적으로 서비스 될 때 문제없는 업무 범위로 생각할 수 있으며, 쇼핑몰 사이트를 예로 들면 제품 판매 컨텐스트(Sales Context), 판매지원 컨텍스트(Support Text) 등과 같이 분류할 수 있습니다. 이런 여러 context 내에 비슷해 보이는 용어가 서로 틀린 의미로 사용될 수 있기 때문입니다.
이런 언어는 주로 업무 위주의 언어를 사용하는 것이 좋습니다. 일반적으로 용어사전(Glossary) 형태로 구성하는 것이 좋으며, 구성원 누구나 쉽게 참조할 수 있도록 합니다. Project Wiki 사이트 등을 운영하여 유지하는 것이 좋은 방법입니다.
주의할 것은 용어사전 형태로 구성한다고 해서 처음부터 모든 용어를 사전처럼 정의하고 프로젝트를 진행하는 것은 불가능합니다. 기본적으로 DDD는 폭포수 개발 방식보다는 애자일 개발방식과 같은 반복 수행을 통한 완성도를 높이는 Model Exploration Whirlpool(모델 개발 소용돌이) 방식을 대부분 채택하고 있습니다. 우선 도메인에 관련된 핵심 업무 관련 모델에 대한 용어부터 정의하고 그 모델에 대한 이해도를 서로 높이면서 차츰 발전시키는 것이 중요합니다.
Eric Evans, Domain-Driven Design
도메인 모델과 소프트웨어 시스템 간의 맵핑이 명확해지도록 도메인 모델을 충실하게 반영하는 소프트웨어 시스템을 설계하라. 도메인에 대한 더 깊은 식견을 반영할 방법을 찾는 순간 소프트웨어 내에서 모델을 더 자연스럽게 구현할 수 있도록 모델을 재검토하고 수정하라. 견고한 유비쿼터스 언어를 지원함과 동시에 두 가지 목적 모두에 잘 부합하는 하나의 모델을 추구하라.
설계에서 사용되는 용어와 기본 책임 할당을 사용해서 모델을 작성하라. 코드는 모델의 표현이 되고 코드에 대한 수정은 모델에 대한 수정이 된다. 효과는 나머지 프로젝트 활동 내내 적절히 파급되어야 한다.