Member 라는 도메인을 만들고 그 외에 사용자가 프로필을 설정하거나 가입을 하는 날짜, 등록을 하는 날짜 등 사용자의 상세 정보를 관리하는 객체는 어떻게 할까?

이제 보통은 Member 도메인 객체에 계속 추가를 하게 되는데 그렇게 되면 하나의 도메인이 거대해지고 서비스가 커질 수록 관리하는 필드가 20개, 30개 이상으로 늘어날 수 있다.

이러한 경우에는 하나의 도메인으로 관리하는 것이 아닌 MemberDetail로 도메인 객체를 추가로 생성해서 관리하는 것도 좋은 방법

• Member 와 MemberDetail 의 사용 빈도가 다르기 때문에 필요한 부분만 호출할 수 있는 장점도 있음

<aside> ❓

그렇다면 각각의 도메인 객체로 관리를 해야할까?

</aside>

만약, Member 와 MemberDetail 각각 도메인을 만들면 각각의 Repository 인터페이스를 만들고 Service 구현체에서는 각각 도메인 모델 객체를 불러와야 해야 할까?

→ 하나의 개념적 Aggregate로 묶어서 마치 하나의 도메인 모델로 움직이도록 한다.

사진에서 Member 와 MemberDetail 객체를 하나의 Aggregate로 묶는다.

• 중심이 되는 부분이 Aggregate Root, 그 외 부분이 Aggregate Member 라고 함.

애그리거트(Aggregate)

DDD에 소개된 도메인 모델 구성 요소/패턴의 하나

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

• 데이터 조회 목적을 가졌다면 경로는 매우 많고 조합도 많다. 여기서 중요한 것은 변경의 목적
  • 데이터 변경 시, 하나의 단위로 취급을 함 → 일관성 강조

**루트(root)와 경계(boundary)**로 나뉘며 경계 내부에는 엔티티와 값 객체가 하나 또는 여러 개가 존재할 수 있다.