이 포스트는 Implementing Domain-Driven Design의 1장을 참고하고 작성합니다.

1. 비즈니스에 도움을 주기 때문이다.

1. DDD의 초점은 비즈니스적으로 중요한 곳에 노력을 투자한다는 것이다. 따라서 과도한 모델링을 하지 않고, 핵심 도메인에 초점을 맞춘다. 즉, 에너지를 중요한 곳에 집중할 수 있다.
2. 구성원이 비즈니스를 더 잘 이해할 수 있도록 돕는다. 도메인의 구체적인 내용이 명시되어 시간이 지남에 따라 두고두고 쓸 수 있다.
3. 도메인 전문가가 소프트웨어 설계에 기여한다. 구성원들이 이해하는 도메인 용어의 싱크를 맞춤으로써, 도메인 전문가와 개발자 사이의 소통을 돕는다. 개발자들은 자주 서비스를 기술적으로 생각하는데, 보다 비즈니스에 집중하게 유도한다. 또한 코드 자체가 도메인 용어를 포함하고 있기 때문에, 도메인 전문가가 코드 자체를 보는 게 한결 수월해지고 자기들의 요구사항이 잘 구현됐는지 확인할 수 있게 된다.
4. 사용자 경험이 개선된다. 도메인의 내용이 사용자에게 스며들어가, 사용자들을 자연스럽게 교육한다. 사용자들은 자기들의 원하는바를 더욱 명확히 알게되고, 회사는 고객의 니즈에 집중할 수 있다. 더 적은 비용으로 더 빠른 생산성을 얻게 되는 것이다.
5. 모델의 경계를 명확히함으로써, 자잘한 부분 때문에 방향이 흔들리지 않게 돕는다. 거시적으로 바라볼 수 있게 되는 것이다.
6. 아키텍처 구성이 좋아진다. 회사 내 모든 팀은 어디서 왜 통합이 필요한지 이해하게 된다.

2. 객체 지향을 추구하게 된다.

도메인 모델을 설계한다는 것은 객체들의 데이터가 아니라 행동에 초점을 맞추게 된다는 것이다. 코드는 읽기 쉬워질 것이고, 세터를 남발하는 것에 비해 버그에 대한 가능성 역시 줄어든다. 객체를 사용하는 클라이언트 입장에서 구체적인 구현 사항에 걱정 없이 쓸 수 있다는 것 역시 큰 장점이다. 이는 어찌보면 객체의 구현보다 인터페이스를 설계하는 것에 초점을 맞춘다는 것인데, 이러한 점에서 TDD와 유사하다고 볼 수 있다.