DDD(Domain Driven Design),애그리거트(Aggregate)
DDD(Domain Driven Design)
성능, 생산성, 안정성 면에서 뛰어난 애플리케이션을 만들기 위해 가장 중요한 영역인 애플리케이션의 설계는 구현보다 더 어렵습니다. 그래서 오래전부터 많은 사람들이 어떻게 하면 좀 더 나은 애플리케이션을 잘 설계할 수 있을까라고 고민한 결과물 중 하나가 바로 DDD(Domain Driven Design)입니다.
DDD(Domain Driven Design)는 도메인 주도 설계 정도로 해석할 수 있는데, 해석 그대로 도메인 위주의 설계 기법을 의미합니다.
도메인(Domain)
도메인은 한 문장으로 "실제로 현실 세계에서 접하는 업무의 한 영역이다" 라고 표현할 수 있습니다.
DDD에서 도메인(Domain)은 애플리케이션 개발에서 흔하게 사용하는 용어입니다. 주로 비즈니스적인 어떤 업무영역과 관련이 있습니다.
예를 들어, 여러분들이 새로운 배달 주문 앱을 만들어야 한다면 고객과 음식점, 배달원, 그리고 카드사 또는 은행 등 배달 주문 앱을 구현하기 위해 필요한 업무들을 자세히 알면 알수록 퀄리티가 높은 애플리케이션을 만들 가능성이 높습니다.
즉, 고객이 음식을 주문하는 과정, 주문받은 음식을 처리하는 과정, 조리된 음식을 배달하는 과정 등의 도메인 지식(Domain Knowledge)들을 서비스 계층에서 비즈니스 로직으로 구현해야 하는 것입니다.
애그리거트(Aggregate)
애그리거트(Aggregate)는 비슷한 업무 도메인들의 묶음을 의미합니다.
비슷한 범주의 연관된 업무들을 하나로 그룹화해놓은 그룹이라고 생각하면 조금 더 이해가 쉬울 것 같습니다.
앞서 언급했던 배달 주문 앱을 예로 들어 애그리거트를 알아보겠습니다.
먼저 배달 주문 앱에서 필요한 업무 즉, 도메인을 정리해야합니다.
회원이 음식을 주문하고, 결제한뒤 배달을 받는다고 생각하면 필요한 도메인을 [회원, 주문, 음식, 배달, 결제] 으로 간단하게 나눌 수 있습니다.
그럼 간단하게 나누었던 도메인들을 조금 더 세분화 해봅시다.
먼저 가지고 있던 [회원, 주문, 음식, 배달, 결제] 도메인을 상위 도메인으로 설정하고, 상위 도메인 하위에 있는 각각의 정보를 하위 도메인으로 설정해서 분류해 보겠습니다.
여기서 배달 주문 앱에서의 애그리거트는 총 4개의 회원 애그리거트, 주문 애그리거트, 음식 애그리거트, 결제 애그리거트
로 구성되어 있습니다.
이렇게 세분화 되어 그룹으로 묶인 비슷한 업무 도메인을 애그리거트(Aggregate)라고 부릅니다.
애그리거트 루트(Aggregate Root)
애그리거트 루트(Aggregate Root)는 애그리거트의 뿌리 즉, 애그리거트 안에 해당 애그리거트를 대표하는 도메인을 말합니다.
위에서 정의한 애그리거트 안에 각각의 애그리거트를 대표하는 도메인 애그리거트 루트(Aggregate Root)를 살펴봅시다.
애그리거트 루트를 선정하려면 기준이 필요합니다.먼저 애그리거트 안에서 해당 애그리거트를 대표하는 도메인이어야 합니다.그리고 각 애그리거트 내의 도메인들 중에서 다른 모든 도메인들과 직간접적으로 연관되어 있는 도메인이어야 합니다.
이런 조건으로 보아 배달앱 애그리거트들 중
회원 애그리거트의 경우 - ‘회원 포인트’가 얼마인지 알려면 해당 포인트를 가지는 ‘회원 정보’를 알아야 합니다. 즉, ‘회원 정보’ 도메인이 애그리거트 루트가 됩니다.
주문 애그리거트의 경우 - ‘주문 정보’가 다른 모든 도메인과 직접적으로 관련이 있습니다. 즉 ‘주문 정보’ 도메인이 애그리거트 루트가 됩니다.
이렇게 데이터베이스의 테이블 간 관계로 보자면, 애그리거트 루트는 부모 테이블이 되고, 애그리거트 루트가 아닌 다른 도메인들은 자식 테이블이 되는 셈입니다.
즉, 애그리거트 루트(Aggregate Root)의 기본키 정보를 다른 도메인들이 외래키 형태로 가지고 있다고 볼 수 있습니다.