🚀 복잡한 시스템을 다루는 4가지 핵심 개념

현대의 소프트웨어는 단순 CRUD를 넘어서 복잡한 도메인 로직과 높은 확장성 요구를 동시에 만족해야 합니다.
이 과정에서 자주 등장하는 개념이 바로 DDD, 에그리거트(Aggregate), 바운디드 컨텍스트(Bounded Context), CQRS, 이벤트 소싱(Event Sourcing) 입니다.

이 글에서는 이 다섯 가지 개념이 어떻게 연결되는지 큰 그림과 흐름을 다루도록 하겠습니다.

📖 1. DDD (Domain-Driven Design)

DDD의 핵심은 도메인 전문가와 개발자가 같은 언어(유비쿼터스 언어)를 사용하여 소프트웨어를 설계하는 것입니다.
단순한 데이터 중심 설계가 아니라 도메인 로직 중심으로 모델을 만들고, 코드와 비즈니스 개념이 일치하도록 하는 것이 목표입니다.

DDD의 주요 개념:

• 유비쿼터스 언어: 도메인 전문가와 개발자가 공유하는 용어 체계
• 바운디드 컨텍스트: 모델의 경계를 명확히 하여 혼란 방지
• 에그리거트: 경계 내부의 일관성을 유지하는 단위

📖 2. 바운디드 컨텍스트 (Bounded Context)

현실 세계의 비즈니스는 크고 복잡합니다. 예를 들어 "회원(Member)"이라는 단어도
결제 시스템에서는 "고객(Customer)"
인사 시스템에서는 "직원(Employee)" 으로 다르게 쓰일 수 있습니다.

이를 해결하는 방법이 바운디드 컨텍스트입니다.

• 각 컨텍스트는 자체적인 모델과 의미를 가집니다.
• 서로 다른 컨텍스트는 명시적인 인터페이스(API, 이벤트)로 통신합니다.
• 결과적으로 경계를 명확히 나눔으로써 모델의 혼란과 충돌을 줄입니다.

예시)

            [ 비즈니스 전체 도메인 ]
                  ┌──────────────┐
                  │   회사 운영   │
                  └──────────────┘
                           │
        ┌──────────────────┼──────────────────┐
        │                                      │
 ┌─────────────┐                       ┌───────────────┐
   결제 시스템                            인사 시스템 
   Payment BC                               HR BC     
 └─────────────┘                       └───────────────┘
        │                                      │
 ┌───────────────┐                       ┌───────────────┐
     Customer                               Employee     
      (고객)                                  (직원)       
    - 이름                                  - 이름        
    - 결제수단                              - 부서        
    - 구매내역                              - 급여        
 └───────────────┘                       └───────────────┘
        │                                      │
        └──────────── 명시적 인터페이스(API/이벤트

📖 3. 에그리거트 (Aggregate)

바운디드 컨텍스트 내부에서도 모든 객체가 뒤엉켜 있으면 유지보수가 어렵습니다.
그래서 일관성 경계(Consistency Boundary)를 정하고 그 안에서 항상 규칙이 지켜지도록 하는 단위가 에그리거트입니다.

• Aggregate Root: 외부에서 접근 가능한 유일한 진입점
• 내부 엔티티(Value Object 포함): Root를 통해서만 접근/수정 가능

예시)

• Order (Root) + OrderItem (내부 엔티티)
• Post (Root) + Comment (내부 엔티티)
• Account (Root) + Transaction (내부 엔티티)

👉 핵심은 트랜잭션은 Aggregate 단위로 보장된다는 점입니다.

📖 4. CQRS (Command Query Responsibility Segregation)

일반적으로 하나의 모델로 읽기와 쓰기를 동시에 처리합니다.
하지만 트래픽이 커지고 복잡도가 올라가면 쓰기(Command)와 읽기(Query)를 분리하는 CQRS 패턴이 등장합니다.

• Command 모델: 상태 변경 담당 (도메인 규칙, 트랜잭션)
• Query 모델: 데이터 조회 담당 (성능 최적화, 캐싱, 별도 저장소)

장점:

• 읽기와 쓰기를 따로 확장 가능
• 복잡한 도메인 로직과 단순 조회 로직 분리

단점:

• 결국 Eventual Consistency(최종적 일관성) 문제를 다뤄야 함
• 단순 CRUD 시스템에는 과도한 설계

예시)

UserRepository는 쓰기용 DB(JPA 기반)
UserReadRepository는 읽기용 DB(캐시 or 조회 전용 DB)로 나눌 수 있다.

📖 5. 이벤트 소싱 (Event Sourcing)

일반적으로 DB에는 "현재 상태"만 저장합니다.
이벤트 소싱은 다른 접근을 택합니다. 상태 변화를 만든 모든 이벤트를 저장합니다.

장점:

• 모든 변경 이력을 100% 보존 (추적 용이)
• 원하는 시점의 상태 복원 가능
• 이벤트를 다른 시스템에 쉽게 전달 가능 (이벤트 드리븐 아키텍처)

단점:

• 이벤트가 많아지면 리플레이 비용 발생 → 스냅샷 필요
• 이벤트 스키마 진화 관리 어려움

예시)

사용자가 주문을 생성/결제/취소하는 과정을 이벤트로 저장

📖 6. 개념들의 연결

이 다섯 가지 개념은 따로 노는 것이 아니라 하나의 스토리를 이룹니다.

• DDD: 복잡한 도메인을 다루기 위한 철학
• 바운디드 컨텍스트: 모델의 경계를 나누는 방법
• 에그리거트: 경계 내부의 일관성을 지키는 단위
• CQRS: 확장성을 위한 읽기/쓰기 분리
• 이벤트 소싱: CQRS와 잘 어울리는 상태 관리 방식

DDD → BC → Aggregate → CQRS → Event Sourcing 이런 흐름으로 연결됩니다.

📖 7. 언제 쓰면 좋을까?

• 단순한 CRUD 서비스 → 필요 없음 (오버엔지니어링)
• 복잡한 비즈니스 규칙 + 높은 확장성 요구 → 적합
• 금융, 이커머스, 로깅/추적 시스템 → 이벤트 소싱 + CQRS 강력 추천

📖 8. 마무리

모두 복잡한 도메인을 효과적으로 다루기 위한 도구입니다.
하지만 "무조건 쓰는 패턴"이 아니라 도메인 특성과 요구사항에 맞춰 선택적으로 적용해야 합니다.

혹시 궁금한 부분이나 더 보고 싶은 주제가 있다면 댓글로 남겨주세요 🙌