[DDD] Aggregate 어그리거트

Aggregate 란 비즈니스에서 밀접한 연관성이 있는 객체들의 군집입니다.

 

DDD 의 모든 구성요소는 명확한 경계와 응집을 통하여

scalable 하고 loose coupled 된 설계를 하는데에 목적이 있습니다.

 

제가 이해한 Aggregate 는 비즈니스의 경계인 Bounded Context 안에 속하는 또 다른 경계. 

바운디드 컨텍스트보다 조금 더 구체적인 개념이 되는 실제 객체의 경계라고 볼 수 있겠습니다.

 

바운디드 컨텍스트가 어플리케이션 기능단위의 경계라면,

어그리거트는 도메인 생명주기 단위의 더 작은 경계라고 생각됩니다.

 

에릭 에반스의 도메인 주도 설계에서는 Aggregate Pattern 을 제시하며

몇가지 룰을 따르면 어그리거트가 가지는 강력한 장점을 활용할 수 있다고 합니다.

해당 포스팅에서는 Aggregate라는 개념이 왜 나왔는지와 Aggregate 룰들을 상세히 소개 해보려합니다.

 

---

Why Aggregate?



일반적으로 객체 모델의 관계망 (객체 탐색 그래프) 는 변경의 효과와 범위를 명확하게 보여주거나 한정짓지 않습니다.

관계를 맺은 상태에 따라 얼마든지 객체 그래프를 탐색할수있고, 또 그로 인해 변경의 영향의 파급효과가 무한대로 퍼질 수 있습니다. 

 

우리는 객체지향개발을 할때, '변경의 이유' 에 따라 캡슐화 하고 추상화 시킵니다. 

바로 변경의 파급효과를 최소화 하기 위해서죠. 하지만 아무리 캡슐화 하더라도 객체의 연관관계에 따라 파급효과가 퍼져나가는것을 막는데에는 한계가 있습니다.  그래서 보통 팀 내에서 비즈니스 룰에 따라 그 범위를 한정짓기도 하는데요.

그럼에도 불구하고 구두로만 전달되는 룰이나, 최신화 되지 않는 문서로인해 결국엔 그 룰이 깨지기도 합니다.

 

그래서 AGGREGATE 라는 명확한 경계를 설계 단계에서 부터 설정하는 것입니다.

책에서는 AGGREGATE 란 데이터 변경의 단위로 다루는 연관객체의 묶음이다. 라고 표현합니다.

 

즉 캡슐화된 모델들의 참조를 기능이라는 또 넓은 범위에서 캡슐화 한것이라고 볼 수 있겠습니다.

AGGREGATE 란 명확한 경계의 개념을 도입함으로서, 항상 수기로 업데이트해야하는 구두 합의나, 문서가 아니라

설계로써 논리적으로 명확한 범위를 인지할 수 있도록 강제하는것입니다.

 

그렇다면 이 Aggregate 를 도입하기 위한 Rule 을 살펴봅시다.

 

 

Aggregate Rule

 

1. 하나의 도메인 객체는 하나의 Aggregate 에만 속합니다.

 Entity 건 Value Object 건 상관없이 도메인 객체는 하나의 어그리거트에만 속합니다.

중첩된 경계를 지닌 객체로 인한 coupling을 허용하지 않습니다.

 

2. 하나의 Aggregate Root 와 연관 객체들로 구성됩니다.

 Aggregate 는 응집된 경계이기 때문에, 내부의 모든 객체들이 동일하거나 거의 유사한 라이프사이클을 지닙니다.

즉 Root 가 삭제될 경우 하위의 모든 연관 데이터들도 삭제되어야합니다. 

해당 룰을 지키기위해, 영속화를 담당하는 Repository 는 Aggregate Root 만이 지닙니다.

 

3. 모든 하위 객체들은 Aggregate Root 를 통하여 접근합니다.

 Aggregate Root 외의 모든 하위 객체들은 Aggregate Root 를 통하여 접근하여야 합니다.

해당 룰로 인하여 모든 하위 객체들의 변경의 이유가 Root 로 응집되어 관리포인트가 줄어듭니다.

 

4. 다른 Aggregate 에서의 참조는 Aggregate Root 의 ID 를 통하여 합니다.

 다른 Aggregate 에서의 참조는 3번 룰에 의하여 Aggregate Root 를 통하여 해야하며,

Aggregate Root 를 참조할 때, 직접 참조가 아닌 ID 를 통한 간접 참조를 이용하여 경계간의 결합도를 낮춥니다.

 

5.하나의 트랜잭션에서는 하나의 Aggregate만 수정합니다.

위 룰을 모두 지켰을때만, 지켜지는 규약입니다. Aggregate는 트랜잭션의 단위가 됩니다.

하나의 트랜잭션에서는 하나의 Aggregate 만 수정하며, 동시에 두가지의 Aggregate 를 수정되는 경우,

비동기 처리가 가능할 경우 이벤트를 발행하거나 간접 참조된 id 를 사용하여 새 트랜잭션 내부에서 처리합니다.

 

---

결론

Aggregate 가 가지는 규칙과, 그로 인한 효과를 기술해보았습니다.

Aggregate는 강력한 장점을 제공하는 만큼, 처음에 제대로된 설계를 하기가 쉽지않습니다.

이전 글들에서 다루었던 이벤트 스토밍이나 여러 방법을 통하여 설계를 해보는 연습을 꾸준히 해야할 것 같습니다.

그리고 단순히 코드를 잘 짜는것 보다, 애초에 설계에서 발생될 문제들을 미연에 방지하고 항상 원칙을 되뇌이며 개발 과정에서 설계를 개선해 나가는 것이 중요하다는것이 한번 더 와닿습니다.