DDD (Domain-Driven Design)
애플리케이션 개발함에 있어서 성능, 생산성, 안정성 모두 뛰어난 애플리케이션을 만들기 위해서는 애플리케이션 설계를 잘하는 것이 중요하다.
어떻게 하면 더 나은 애플리케이션을 잘 설계할 수 있는지에 대해 고민하여 얻은 여러 결과물 중 하나가 DDD (Domain-Driven Design), 도메인 주도 설계다.
DDD는 굉자히 뛰어난 설계 및 구현 기법이지만, DDD의 개념을 완벽히 이해하는 것은 쉽지 않고, 많은 학습과 설계 경험이 필요하다.
Domain
애플리케이션 개발에서 사용하는 도메인이라는 단어는 비즈니스적인 어떤 업무 영역과 관련이 있다. 도메인을 쉽게 이해하기 위해 음식 주문 배달 애플리케이션을 만든다고 가정을 해보면
음식 주문 배달 애플리케이션은 음식을 주문하는 고객, 주문받은 음식을 만들고 판매하는 음식점, 완성된 음식을 배달하는 배달원, 해당 음식을 주문하고 결제하는데 사용되는 카드사 or 은행이 필요하다.
이것들을 각각의 도메인이라고 불릴 수 있다. 이렇게 애플리케이션을 구현하기 위해서는 필요한 업무들을 자세히 구분하면 좋은 애플리케이션을 만들 가능성이 높아진다.
해당 업무에서 고객이 음식을 주문하는 과정, 주문받은 음식을 처리하는 과정, 조리된 음식을 배달하는 과정 등 도메인 지식들을 서비스 계층에서 비즈니스 로직으로 구현해야하는 것이다.
즉, 도메인은 현실에서 접하는 업무의 한 영역을 말한다. 음식 주문 배달 애플리케이션에서 필요한 도메인을 대략적으로 추출해보면 회원, 주문, 음식, 결제 등이 상위 도메인이 된다.
상위 도메인을 조금 더 세분화를 해보면 다음과 같은 하위 도메인들을 표현할 수 있다.
하위 도메인
- 회원: 회원 정보, 회원 포인트
- 주문: 배달 주문자, 배달 정보, 주문 정보, 배달 추적 정보, 배달 주소 정보
- 음식: 음식 정보
- 결제: 결제 정보
애그리거트 (Aggregate)
애그리거트는 비슷한 업무 도메인들의 묶음이다. 위에 도메인을 설명한 것중 상위 도메인을 나눴는데 그 예시들에서 애그리거트의 개수는 4개가 된다.
이를 회원 애그리거트, 주문 애그리거트, 음식 애그리거트, 음식 애그리거트, 결제 애그리거트 등으로 부를 수 있다.
애그리거트는 도메인보다 복잡하고 어려운 개념이지만, 비슷한 범주의 연관된 업무들을 하나로 그룹화한 것으로 생각할 수 있다.
애그리거트 루트 (Aggregate Root)
위에서 정의한 애그리거트에는 1개 이상의 도메인들이 있다. 따라서, 각각의 애그리거트에서는 해당 에그리거트를 대표하는 도메인이 존재하게 된다.
이처럼 하나의 애그리거트를 대표하는 도메인을 DDD에서는 애그리거트 루트라한다. 애그리거트 루트를 예시로 간단하게 설명하자면, 여러 개의 동으로 구성된 아파트로 설명할 수 있다.
- 1, 2, 3동으로 구성된 아파트가 존재한다고 가정
- 아파트 각 동을 대표하는 동대표가 1명씩 있음.
- 동대표는 동에 거주하는 입주민을 대표해서 의견 전달하고, 주거 환경을 개선하는 등의 일을 함.
- 이러한 동대표를 애그리거트 루트라고 표현할 수 있음.
애그리거트 루트 선정
애그리거트 내의 도메인들 중 다른 모든 도메인들과 직/간접적으로 연관이 되어 있는 도메인들을 발견할 수 있다. 특정 도메인이 다른 모든 도메인들과 연관이 있다면 애그리거트 루트로 선정할 수 있다.
- 회원 애그리거트
- 회원 포인트가 얼마인지 알려면 해당 포인트를 가지는 회원 정보를 알아야한다. 따라서 회원 정보 도메인이 애그리거트 루트가 된다.
- 주문 애그리거트
- 주문 정보는 다른 모든 도메인과 직접적으로 연관이 있다. 따라서 주문 정보 도메인이 애그리거트 루트가 된다. (주문자 정보, 음식 정보 등)
- 음식 애그리거트
- 음식 정보가 애그리거트 루트가 된다.
- 결제 애그리거트
- 결제 정보가 애그리거트 루트가 된다.
이렇게 정리한 것들을 데이터베이스의 테이블 간 관계로 표현할 수도 있다. 모든 애그리거트 루트는 부모 테이블이 되고, 애그리거트 루트가 아닌 다른 도메인들은 자식 테이블이 되는 것이다.
즉, 애그리거트 루트의 기본키 정보를 다른 도메인들이 외래 키 형태로 가지고 있는 것이다.
