AGGREGATE가 존재하는 이유?

도메인과 도메인간에 연관관게를 최소주의 관점에서 설계하면 탐색이 단순해지고 폭발적으로 증가하는 관계를 제한하는 데 어느 정도 도움되지만 대부분의 업무 도메인은 상호 연관의 정도가 높아 결국 객체 참조를 통해 얽히고 설킨 관계망을 추적해야 한다.

그럼 얽히고 설킨 관계망을 어떻게 추적할 것인가?

또한, 모델 내에서 복잡한 연관관계를 맺는 객체를 대상으로 변경의 일관성을 보장하기란 쉽지 않다. 그 까닭은 단지 개발 객체만이 아닌 서로 밀접한 관계에 있는 객체 집합에도 불변식이 적용돼야 하기 때문이다. 그렇다고 변경의 일관성을 보장하고자 신중 장금 기법을 쓴다면 다수의 사용자가 서로 부적절하게 간섭해서 시스템이 사용할 수 없는 상태가 될 것이다.

그럼 우리는 도메인과 도메인간의 또는 모델 내에서 어떻게 관리할 수 있을까?

예를 들어 설명해봅시다.

자동차 수리점에서 사용하는 소프트웨어가 있다.

자동차 번호판은 그 차의 식별자가 될 것이기 때문에 자동차라는 도메인이 존재한다. 그렇다면, 타이어라는 도메인도 엔티티 객체로 가질 수 있을 것입니다. 종류, 마모상태 등을 파악할 때 이 또한 엔티티 객체로 가질 수 있을 것입니다. 그러나 만약 타이어와 자동차의 AGGREGATE를 따로 둔다면 어떤일이 일어날까?

타이어의 교체 히스토리나, 마모 상태를 조회하기 위해서는 타이어의 고유번호를 조회해야할 것이다. 이렇게 될 경우, 관리되는 포인트가 서로 다르기 때문에 타이어의 식별번호를 방치하는 일이 발생할 수도 있고, 자동차를 조회하더라도 타이어의 상태를 알 수 없는 상태를 만들 수도 있다.

이번에는 만약 같은 AGGREGATE로 놓는다면 어떻게 될까? 자동차의 식별번호를 통해 타이어의 식별번호에 접근하고, 마모상태를 확인할 수 있을 것이다.

우리가 가진 모델 내의 참조에 대한 캡슐화를 추상화할 필요가 있습니다. 그것이 바로 AGGREGATE의 시작입니다. AGGREGATE는 우리가 데이터 변경의 단위로 다루는 연관 객체의 묶음을 말합니다. AGGREGATE는 루트와 경계각 있으며, 각 경계는 무엇이 포함되고 포함되지 않는지를 정의합니다.

루트는 단 하나만 존재하며, AGGREAGTE에 포함된 특정 ENTITY를 가리킵니다. 경계 안의 객체는 서로 참조할 수 있지만, 객체 바깥의 객체는 해당 AGGREGATE의 구성요소 가운데 루트만 참조할 수 있습니다. 루트 이외의 ENTITY는 지역 식별성(local identity)을 지니며 지역 식별성은 AGGREGATE 내에서만 구분되면 됩니다. 이는 AGGREGATE 경계 밖에 위치한 객체는 루트 ENTITY의 컨텍스트 말고는 AGGREGATE의 내부를 볼 수 없기 때문입니다.