애그리거트를 이용한 일관성 있는 도메인 모델 설계(작성중)

도메인 주도 설계(DDD)에서 애그리거트(Aggregate)를 정의하는 주된 목적?

경계 내 객체들의 데이터 일관성을 보장하는 것이 주된 목적

 

시스템의 다른 부분에서 애그리거트의 데이터나 기능에 접근할 때 일반적으로 애그리거트 루트를 통해 접근.

애그리거트 내부는 보호되며, 모든 외부 접근 및 변경 요청은 애그리거트 루트를 통해서만 이루어져야 합니다. 이는 불변식 유지를 돕습니다.

 

회원 애그리거트(Member + MemberDetail)와 같이, JPA를 사용하여 애그리거트 전체의 데이터 영속성을 관리하는 일반적인 방법은 무엇인가요?

Member(Root) 저장 시 Cascade로 함께

JPA에서 애그리거트 루트(Member)에 Cascade 타입을 설정하면, 루트를 저장하거나 삭제할 때 관계된 내부 엔티티(MemberDetail)도 함께 영속화됩니다.

 

애그리거트 경계 내의 '불변식(Invariant)'은 무엇이며, 언제 유지되어야 할까요?

애그리거트의 모든 변경 작업 시 항상 참인 조건

불변식은 애그리거트 경계 내 객체들의 상태가 항상 만족해야 하는 조건입니다. 애그리거트의 어떤 변경이 발생하든 불변식은 반드시 유지되어야 합니다.

 

 도메인 모델의 핵심 로직 정확성을 검증하기 위해 테스트 노력을 집중해야 한다고 강조한 주된 영역?

도메인 모델 (애그리거트 루트).

핵심 비즈니스 규칙과 로직은 도메인 모델, 특히 애그리거트 루트에 응집되어 있습니다. 이곳에 대한 테스트를 철저히 해야 로직의 정확성을 보장할 수 있습니다.

----------------

 

엔티티에 커짐에 따라 사용 빈도가 다른 부분을 분리할 수 있다.

ex) 회원 엔티티 → 회원 상세 엔티티

 

그럼 서비스에서 두 객체를 각각 생성해줄 것인가?

사실 하나의 개념을 둘로 분리한 것인데, 서비스에서 할 일이 3개나 늘어났다.

1. Member 생성

2. MemberDetail 생성

3. Member, MemberDetail 연결

4. Member Repository 저장

5. MemberDetailRepository로 저장

 

변경 시 각각 변경해야하는 것은 물론이고..

 

이런 엔티티가 더 생성된다면..?

 

이럴 때 사용할 수 있는 전략이 있다.

둘을 하나의 하나의 단위로 묶는 것이다. 그 단위를 Aggregate라고 한다.

그리고 외부에서 변경이 생길 때는 Member에만 접근한다.

 

{사진}

 

애그리거트 루트가 저장될 때 애그리거트 멤버도 같이 저장되게 한다.

 

애그리거트(Aggregate)

일관성을 유지해야 할 도메인 객체들의 묶음.

도메인 주도 설계(DDD)에 소개된 도메인 모델 구성 요소/패턴의 하나이다.

데이터 변경의 목적을 위해 하나의 단위로 취급되는 연관된 객체들의 클러스터이다.

루트(root)와 경계(boundary)를 가진다.

 

애그리거트의 특징

데이터 변겨 시 하나의 단위로 취급: 데이터 변경의 일관성을 유지하기 위해.

루트를 통한 접근 제어: 외부 객체는 루트 엔티티에만 참조를 가질 수 있다.

 

* 데이터 일관성 유지

- 경계 내의 어떤 변경 사항이 있을 때 전체 애그리거트의 모든 불변식이 충족되어야 한다.

(ex. 이체 시 a 계좌 잔액과 b 계좌 잔액 합이 이전과 동일 / 멤버 상세에도 등록 시간이 있어야 한다. )

- 애그리거트를 넘어서는 불변식은 이벤트나 배치 등을 토해 특정 시간 내에 해결할 수 있다.

- 검색 및 접근 방식: 리포지토리를 통해서 애그리거트 루트만 직접 얻을 수 있다.

    - 내부 엔티티는 루트로부터 연관관계를 통해서 접근한다.

- 생명관리 주기 캡술화: Factory와 Repository를 이용해서 객체들을 생명주기에 걸쳐 체계적이고 의미있는 단위로 조작

 

애그리거트의 목표

일관성 유지: 

이해 용이성:

트랜잭션과 동시성 관리: 경계가 분명해짐

모델 단순화: 연관관계 탐색을 제한. 거미줄처럼 이것저것 얽히지않아.

 

 

애그리거트 적용 방법

JPA의 cascading을 적절하게 활용

리포지토리는 

JPA 핵심 원칙: Repository<T, ID>에서 T = Aggregate Root

가능한 하나의 트랜잭션에 하나의 애그리거트만 변경. 하나의 애그리거트를 두개의 트랜잭션으로 나누는 것은 금지.

 

 

적용의 어려움

경계 잡기가 어렵다.

도메인 이벤트와 최종적 일관성(eventual consistency)의 사용이 요구된다.

 

헥사고날 아키텍처와 애그리거트

애그리거트 단위로 애플리케이션(헥사곤)을 구성하는 방법이 유용하다

id를 통해서, 레퍼런스를 갖고있따고 하더라도 id로. web api 등과 동일하게 가면 좋으니까.

 

 

 

---

참고 자료 & 이미지 출처
토비의 클린 스프링 - 도메인 모델 패턴과 헥사고날 아키텍처