DDD Aggregate (애그리게이트) 알아보기

DDD에서 유독 어렵다고 유명한 개념인 Aggregate에 대해서 알아보겠습니다!

DDD 자체에 관한 글을 아래 2개 글을 참고해 주세요.

DDD, 난해한 용어 없이 상식적으로 이해하기

핵사고날? 클린 아키텍처? DDD?

---

간단한 예시

DDD에서 모델링을 진행하면 여러 관련 Entity와 VO들이 나옵니다. 이런 객체들이 꼭 구현 상세 (보통은 DB의 TABLE 이겠쬬...?)과 일치하지는 않지만, 자연스럽게 그렇게 되는 경우도 많습니다. (보통 실용적인 이유로...)

예를 들어 간단한 커뮤니티 기능을 모델링 한다면 아래와 같은 Entity들이 나올 수 있습니다.

• Post
• Post Like
• Comment
• Comment Like

이 모든 값들은 게시글 1개를 나타내기 위해 있기 때문에 이걸 묶고 싶을 수 있습니다.

data class Posts(
    val post: PostEntity,
    val postLikes: List<PostLikeEntity>,
    val comments: List<CommentEntity>,
    val commentLikes: Map<CommentEntity, List<CommentLikeEntity>>,
)

 

요렇게 하면 게시글을 조회하거나 수정/삭제를 할 때 Posts를 변경하면 내부에서 알아서 처리해 주기 때문에 굉장히 편리할 수 있습니다. (하지만 이건 좋은 Aggregate가 아닙니다. 자세한 건 밑의 Aggregate를 나누는 기준을 참고해 주세요.)

---

조금 더 엄밀한 정의

Aggregate	1개로 취급할 여러 Entity, VO들을 묶어 놓은 것
Aggregate Root	Aggregate를 표현하는 Entity
Repository	Aggregate Root를 가져올 수 있는 Service

 

제한

• 모든 Aggregate는 Aggregate Root로만 변경이 가능해야 합니다.
• 모든 Aggregate Root는 Repository를 통해서만 받아올 수 있습니다.
• Aggregate Root는 다른 Aggregate에 속할 수는 없습니다. (ID로 참조해야 합니다.)

---

Aggregate를 나누는 기준?

어떤 Entity, VO를 같은 Aggregate로 묶을 지는 사실 예술에 가까운 영역입니다. 일단 간단한 고려사항은 3가지 정도가 있습니다.

1. 얼마나 같이 변경 되냐?
2. 얼마나 서로가 필요하냐? (상호작용 하냐?)
3. 얼마나 연관이 있냐? (같은 Bounded Context에 있고, 개념적으로 비슷하고 등)

 

위에 Posts의 예시는 서로 연관이 있고 같이 조회되는 게 맞지만, 같이 변경되지는 않습니다. 이런 경우 Aggregate로 묶어도 될까요? 

• 개념적으로 상관은 있지만 댓글이 엄청 많이 변경될 동안 게시글 자체는 1번도 변경되지 않을 수 있습니다.
• 서로 연관이 크게 없습니다. 주문/배송을 같은 Aggregate로 묶을 경우 배송이 특정 상태일 때만 주문을 취소할 수 있다던가 하는 규칙을 적용하기 위해 Aggregate로 묶으면 좋지만, 게시글/좋아요/댓글 사이에는 이런 관계가 딱히 없습니다.

따라서 이 경우는 좋은 Aggreagte라고 할 수 없습니다.

즉, Aggregate는 단순히 개념적으로 비슷하다고 묶는 게 아니라 함께 변경돼야 하고, 함께 일관성을 유지해야 하는 최소한의 것들만 포함하는 게 좋습니다.

---