---
created: 2025-12-24 04:30
updated: 2025-12-25 02:00
author: Jeon MinJi
topics:
- "300-백엔드개발"
types:
- "이론"
tags:
- ddd
- aggregate
- 도메인주도설계

Aggregate란 무엇인가

도메인 주도 설계(DDD)에서 관련된 객체들을 하나의 단위로 묶어 관리하는 개념

왜 필요할까

비즈니스 로직을 처리할 때 여러 테이블이 연관되는데, 이들을 어떻게 묶어서 관리할지가 중요하다. Aggregate는 트랜잭션의 경계를 명확히 하고 데이터 일관성을 보장하기 위한 개념이다.

Aggregate 설계 패턴 비교

1. 유즈케이스 단위에 관여된 모든 테이블을 Aggregate로 묶는 경우

문제점:
포인트 적립 시스템의 로직에 오류가 있을 경우 주문 자체가 이루어지지 못함

고객 입장에서 생각해보라. 배가 고픈데, 포인트 적립에 문제가 생겨 주문이 롤백된다. 얼마나 슬픈 일인가!

교훈: 핵심 비즈니스 로직과 부가 기능을 하나의 트랜잭션으로 묶으면 안된다.

2. 모든 테이블을 하나의 Aggregate로 정의한 경우

문제점:

• 전체 주문금액과 주문 내역이 일치하지 않음
• 주문 내역 일부가 누락 혹은 중복 입력 가능
• (1 Submit = 1 Aggregate Operation)

빵과 우유를 먹고 싶었는데, 우유가 누락됐다면 목이 메인다. 얼마나 슬픈 일인가!

교훈: Aggregate 범위가 너무 넓으면 데이터 정합성을 보장하기 어렵다.

3. 불변식(Invariant) 범위만을 Aggregate로 잡은 경우 (권장)

핵심 원칙:

• 불변식: "주문 총량과 주문 내역 합산은 같아야 한다"
• ACID 트랜잭션이 필요한 최소한의 Entity(테이블) 묶음만 포함
• Point는 천천히 처리되어도 괜찮다 (Eventual Consistency)

왜 이렇게 했냐면:

• 주문과 주문 내역은 반드시 동시에 일관성을 유지해야 함
• 포인트는 나중에 적립되어도 비즈니스에 큰 영향이 없음
• 트랜잭션 범위를 최소화해서 성능과 안정성을 모두 확보

결론

Aggregate 설계 시 핵심은 "불변식을 보장해야 하는 최소 범위"를 찾는 것이다. 너무 크면 성능 문제가 생기고, 너무 작으면 데이터 정합성이 깨진다.

관련 문서: 핵사고날아키택처, 이벤트 기반 아키텍처(EDA)의 정합성