DDD는 Domain Driven Design, 즉 도메인 주도 설계이다.
도메인을 중심으로 애플리케이션을 설계, 구성하는 방법이다.
도메인이란 '소프트웨어로 해결하고자 하는 문제 영역'을 의미한다.
한 도메인은 다시 하위 도메인으로 나눌 수 있고, 도메인들은 서로 연동하여 완전한 기능을 제공한다.
이 도메인은 소프트웨어의 요구사항을 이해하는데 중요한 요소이다. 서비스를 통해 어떤 문제를 해결할 것인지, 어떤 도메인을 다룰 것인지, 도메인끼리의 관계가 어떠한지 확실하게 알아야 요구사항을 제대로 이해하고 개발을 효율적으로 진행할 수 있다.
도메인은 사용자가 누구인가, 어떻게 사용하냐에 따라 같은요소라고 할지라도 계속 바뀔 수 있고, 형태가 고정되어있지 않은 추상적인 요소이다.
하지만 소프트웨어의 여러 관계자들은 모두 도메인을 잘 이해하고 있어야하기 때문에, 도메인에 적절한 이름을 붙이고 도메인 모델을 구체적으로 표현해보는 과정이 필요하다.
도메인 모델링을 하기 위해선 아래의 두가지 요소를 먼저 찾아야한다.
- 도메인이 제공하는 기능
- 도메인의 주요 데이터 구성
위 요소가 잘 드러나록 도메인 모델을 작성해야한다. 도메인 모델을 표현하는 방법에는 여러 가지가 있다. (상태 다이어그램, 클래스 다이어그램, UML 표기법 등)
주문 도메인을 잘 이해할 수 있도록 도메인 모델을 작성한 모습이다.
도메인 모델을 사용하면 여러 관계자들이 동일한 모습으로 도메인을 이해하고 도메인 지식을 공유하는데 도움된다.
다른 사람들이 빠르게 이해할 수 있도록 도메인을 문서화한다고 얘기할 수 있다.
위에서 말했듯, 도메인은 사용자가 누구인가, 어떻게 사용하냐에 따라 같은요소라고 할지라도 계속 바뀔 수 있다. 논리적으로는 같은 존재처럼 보이지만 하위 도메인에 따라 다른 용어를 사용하는 경우도 있다.
하위 도메인에 따라 다른 용어를 사용할 수 있다는 것은, 문맥이나 환경에 따라 같은 물체도 다른 의미를 지닐 수 있다는 뜻이다. 즉, 모델은 특정한 컨텍스트(문맥) 하에서 완전한 의미를 가진다.
DDD에서는 도메인의 문맥을 나누는 경계를 **바운디드 컨텍스트(Bounded Context)**라고 부른다.
바운디드 컨텍스트의 경계를 지을떄는 전문가, 관계자, 개발자가 사용하는 도메인과 관련된 공통의 언어가 필요한데, 그것을 유비쿼터스 언어(Ubiquitous Language)라고 한다.
유비쿼터스 언어는 도메인 전문가와 소프트웨어 엔지니어와의 원활한 소통을 위해 사용된다.