도메인 주도 설계는 복잡한 비즈니스 요구 사항을 해결하기 위해 도메인에 집중하고, 해당 도메인에 대한 깊은 이해를 바탕으로 설계를 이끌어가는 접근 방식이다.
여기서 도메인은 해당소프트웨어가 해결하려는 특정 비즈니스 문제나 영역을 의미하며, 크게 전략적 설계와 전술적 설계로 나뉜다.
전략적 설계는 시스템의 큰 그림을 다루는 개념으로, 도메인과 그 서브 도메인, 그리고 이들이 어떻게 서로 상호작용하는지를 정의한다.
또한, 개발자와 비즈니스 전문가들이 소통할 때 동일한 개념을 더 잘 이해할 수 있도록 공통된 언어를 정의하고 사용하며, 이것을 유비쿼터스 언어라고도 부른다.
그 외에도 도메인을 하위 도메인으로 나누어 더 작은 범위에서 집중적으로 모델링하는 바운디드 컨텍스트라는 개념과 이 바운디드 컨텍스트 간의 관계를 정의하는 컨텍스트 매핑이라는 개념이 존재한다.
전술적 설계는 시스템의 세부 설계를 다루고, 구체적인 구현과 관련된 원칙과 패턴을 정의한다.
주요 개념으로 Entity, 값 객체 VO, Aggregaste, Repository, Service , 도메인 이벤트 등이 있다.
Entity는 고유한 식별자를 가진 객체를 나타내고, VO는 식별자가 없고, 주로 불변 속성으로 정의되는 객체를 의미한다.
Aggregaste는 여러 Entity와 VO를 묶어 하나의 단위로 관리하는 구조로, 논리적으로 관련된 객체들을 그룹화해서 하나의 묶음으로 다루는 것을 의미한다.
도메인 이벤트는 도메인 모델 내에서 중요한 사건이나 상태 변경을 나타내는 객체로, 시스템 내의 다른 부분에 변화가 있음을 알려주는 역할을 한다.
DDD의 장점은 복잡한 비즈니스 요구 사항을 코드에 명확하게 반영할 수 있으며, 비즈니스 전문가와 개발자 간의 의사소통을 원활하게 할 수 있다는 점이다.
또한 시스템을 작은 컨텍스트 단위로 나누어 이해하고 유지보수하기 쉽다는 장점이 있다.
주로 복잡한 비즈니스 도메인을 다룰 때 유용하며, 특히 여러 하위 도메인이 존재하고, 각 도메인이 독립적이면서도 상호 작용하는 시스템을 설계해야하는 경우 효과적이다.
🌟 추가 질문
📍 DDD와 마이크로 서비스의 관계는?
DDD(도메인 주도 설계)는 마이크로서비스 아키텍처와 밀접한 관련이 있다.
마이크로서비스를 나누는 기준을 개발자가 혼자 결정하는 것이 아니라, 비즈니스 전문가와 개발자가 함께 해당 도메인에 대해 논의하는 방식이 바로 DDD의 핵심이다.
회사에서도 보통 도메인별로 개발팀이 나뉘어져 있으며, 팀 내에서 개발자와 비즈니스 전문가가 소통하면서 도메인을 좀 더 비즈니스에 적합한 방식으로 나누어 개발하게 된다. 이로 인해 테이블 설계나 시스템 구성도 사용자가 이해하기 쉬운 방식으로 만들어지는 것이 이상적인 방향이다.
참고 자료
(2) DDD의 도메인과 바운디드 컨텍스트 - 개발보다는 설계부터!
DDD(Domain Driven Design)
[우테코] Domain Driven Development(도메인 주도 개발)이란?