0. 알아보게 된 이유
Hexagonal Architecture를 학습하면서 자연스럽게 함께 등장하는 개념인 DDD(Domain-Driven Design)가 무엇인지 제대로 이해해보고 싶었다.
예전에 스터디 형식으로 DDD를 학습하려고 시도한 적이 있었지만 끝까지 완주하지 못했고, 개념도 명확하게 정리되지 않은 상태로 남아 있었다.
이번에는 DDD의 모든 내용을 깊게 파고들기보다는,
DDD를 사용하는 목적이 무엇인지,
그리고 실제로 설계를 할 때 어떤 구조와 기준으로 모델을 나누는지에 대해
전체적인 흐름을 이해하는 것을 목표로 학습을 진행하려고 한다.
1. DDD(Domain-Driven Design)란 무엇인가?
DDD는 복잡한 비즈니스 로직을 잘 다루기 위해 설계의 중심을 업무 영역(도메인)에 두는 개발 방법이다.
기술 중심 설계가 아닌 도메인 중심 설계를 목표로 한다.
2. 왜 DDD 인가
실무에서는 의사소통의 불일치로 인해 요구사항 해석이 달라지거나, 구현 방향이 어긋나는 문제가 자주 발생한다.
- 현실에서 자주 마주하는 문제
- 요구사항이 지속적으로 변경된다.
- 비즈니스 로직이 점점 복잡해진다.
- 이해관계자마다 같은 대상을 서로 다른 표현과 의미로 이해한다.
이러한 문제는 코드 구조의 문제가 아니라, 도메인을 이해하는 방식의 문제에서 비롯되는 경우가 많다.
DDD가 제시하는 접근 방식- 먼저 업무 영역, 즉 도메인을 중심으로 모델링한다.
- 모델링한 도메인을 기반으로 코드를 구현한다.
- 이해관계자들이 동일한 개념과 용어를 사용할 수 있도록
- 유비쿼터스 언어(
Ubiquitous Language)를 맞춘다.
결국 DDD의 목적은 단순히 설계 기법을 적용하는 것이 아니라, 변화하는 요구사항과 복잡한 비즈니스 로직 속에서도 지속적으로 유지보수가 가능한 구조를 만드는 것이라고 볼 수 있다.