도메인 주도 설계 - Aggregates

도메인 주도 설계 책을 보다보면 Aggregation Root가 반드시 나오게 됩니다. 논리적으로 엔티티와 Value Object들의 집합이라고 되어 있습니다. 하지만, 이것에 대해 정확히 이해를 하는 것은 조금 까다롭습니다.

가장 보편적인 예로 나오는 것은 주문-주문 상세 내역의 부모 자식간의 관계를 Aggregation으로 묶고, 주문이 Root가 되는 것입니다. 예제를 보면 상당히 심플한데 실제 개발 시 이것을 구분하는 것은 어떤 관점에서 보느냐에 따라 까다롭기도 합니다.

예를 들어 보죠. "국가 - 주 - 도시"라는 관계를 가지는 엔티티들의 집합이 있다고 생각해 봅시다. 그러면 국가만 Aggregation Root가 되는 것일까요? 더 이상 Aggregation으로 쪼갤 필요가 없는 것일까요? 아마 많은 분들이 더 이상 쪼갤 필요가 없다고 생각할지도 모르겠습니다.

하지만, 국가 - 주 각각이 Aggregation Root가 되어야 합니다. 국가 하위에 주가 있고, 주 하위에 도시가 있는 논리적 구조이지만, 새로운 주가 국가에 추가될 수도 있고, 새로운 도시 역시 주에 추가될 수도 있습니다.  상황에 따라서는 도시도 Aggregation Root가 될 수도 있습니다. 일반적으로 Aggregation Root만 Repository를 가지게 되기 때문에 국가만 Root라고 생각한다면 CountryRepository만 존재하게 됩니다. 만약 새로운 도시에 생겼을 때 이 레파지토리를 통해 새로운 도시를 추가할 수 있을까요? ProvinceRepository가 없이는 가능하지 않습니다. 그렇기 때문에 주(State)도 역시 Aggregation Root가 되어야 하는 것이죠. 만약에 주문이라는 엔티티에 주문자의 도시를 저장하고 싶습니다. 이런 비즈니스 요건이 있게 되면 도시 또한 Aggregation Root가 될 수 있습니다.

그러면 어떻게 Aggregation을 만들고 Root를 정할 수 있을까요? 바로 엔티티의 라이프 사이클과 엔티티 간의 연간관계를 보면 됩니다. 주문 상세는 주문이 생성될 때 같이 생성되고 없어질 때 같이 없어집니다. 새로운 주문 상품을 이미 존재하는 주문에 추가하는 비즈니스 로직은 존재하지 않습니다. 이럴 경우 최상위 엔티티가 Aggregation Root가 되며 그 하위에 엔티티들이 존재할 수 있습니다. 주, 도시의 경우는 위와 같은 비즈니스에 부합되지 않으며 이럴 때 각각이 Aggregation Root가 되게 됩니다. 또한 주문에 도시에 대한 관계가 설정될 경우 도시도 Aggregation Root가 되는 것이지요.

Aggregation을 위해서는 엔티티의 라이프 사이클과 클래스 연관 관계를 보면 쉽게 Aggregation을 만들고 Root를 찾을 수 있으니 꼭 기억하세요.