[DDD] Repository

애그리거트

애그리거트는 하나의 Root Entity와, 엔티티와 관련된 정보를 포함하는 Value Object들로 구성된다.

예로,
Mebmer의 경우 root 엔티티는 Member의 이름, id, password 등으로 구성되며
Address와 같이 부가적이지만 많은 정보를 포함하는 것은 Value Object로 따로 빼서 관리한다.

외부에서는 entity 내의 value object에 직접 접근할 수 없으며 value object의 데이터를 이용하거나 변경하는 경우 반드시 root entity를 통해햐 한다.

그렇게 해야 root entity가 모르게 value object가 별개로 변경되는 일이 없고 필요한 도메인 규칙을 일관되게 적용하며 데이터를 변경하거나 읽을 수 있기 때문이다.

애그리거트와 Repository

하나의 Member 당 여러 개의 Address를 저장하거나, Address처럼 여러 개의 필드(컬럼)를 갖는 경우, Member와 Address를 분리하여 Table을 생성하고 관리할 수 있다.

Address 테이블은 주소 정보를 저장하기 위한 컬럼과 Member에 대한 참조 값을 가지고 있을 것이다.

이처럼 Member와 Address가 DB에서 따로 분리되어 관리되는 경우, 각각의 Repository를 생성해야 할까?

그렇지 않다.

Address는 위와 같은 특성 때문에 테이블은 분리되었으나 기본적으로 Member와 거의 동일한 생명주기를 가지면서 반드시 Member를 통해 관리되어야 한다.
따라서 Address에 대한 영속성 관리도 MemberRepository를 통해 이뤄져야 한다.

Address 뿐 아니라, Member에 포함된 모든 Value Object들이 위와 같은 이유로 MemberRepository를 통해 영속성이 관리되어야 한다.

다 대 다 관계를 표현하는 Table은 어느 Repository 에서 관리되어야 할까?

Member 안에서 관리되는 Value Object들은 root entity의 Repository에서 관리되어야 하는 것은 명확하다.

그렇다면,
Team과 Member 와 같이 다 대 다 관계를 갖는 경우,
TeamAndMember같은 두 엔티티 간의 관계를 나타내는 테이블은 어디에서 관리되어야 할까?

TeamAndMember는 member의 id와 team의 id, 그리고 기껏해야 해당 관계가 생성된 시간 정보를 포함하는 정도일 것이다.

즉, 어느 애그리거트에 직접적으로 속하지 않고 두 애그리거트 밖에 위치한 value object인 셈이다.
이런 경우, 비즈니스 관점에서 접근해야 할 것 같다.

1. TeamAndTeamRole을 엔티티화 한다.

단순히 두 엔티티 간의 관계를 표현하는 것을 넘어, 더 복잡한 정보와 기능을 갖춘 하나의 애그리거트로 승격시켜 전용 repository에서 관리하는 것이다.
흔하게 쓰일 것 같지는 않지만 특수한 경우에는 고려해볼 수 있을 것 같다.

2. 한쪽에서 주된 관리

관계의 한 쪽이 도메인 운영 측면에서 더 우세한 경우 연결된 리포지토리가 연결을 처리할 수 있다. 예를 들어 주로 팀에서 구성원을 추가/제거하는 경우 'TeamRepository'가 이 관계의 지속성을 처리할 수 있다.

3. 양쪽에서 관리

두 저장소(TeamRepository 및 MemberRepository)가 책임을 공유할 수 있다. 예를 들어 팀에 구성원을 추가할 때 'TeamRepository'는 연결 테이블 업데이트를 담당할 수 있다. 반대로 구성원이 속한 팀을 쿼리할 때 MemberRepository는 연결 테이블을 쿼리할 수 있다.
선택하는 전략은 도메인, 관계에서 수행될 작업의 특성 및 유지해야 하는 일관성 경계에 따라 다를 것이다.

DDD의 본질은 도메인을 정확하게 모델링하고 기술적 결정이 도메인의 요구 사항과 일치하도록 보장하는 것을 기억해야 한다. 데이터 스토리지의 기술적 측면뿐만 아니라 도메인의 의미론과 일관성 경계에 초점을 맞추는 것이 필수적이다.