[Domain] 객체의 lifecycle 과 Aggregate

[rhakdnj]

생명주기 동안 무결성을 유지해야 하며 생명주기를 관리해주어서 모델이 난해해지는 것을 방지한다.

DDD에서는 이를 해결하기 위해 Aggregate(집합체), Factory, Repository 3 가지 패턴을 제시한다.

• Aggregate: 도메인 객체의 무결성을 유지하며 소유권과 경계(boundary)를 명확하게 해준다. 또한 객체간의 연관관계(association)이 혼란스럽지 않도록 해준다.

• Factory: 복잡한 객체 및 Aggregate를 생성하고 재구성하며 내부 구조를 캡슐화한다.

• Repository: 생명주기의 중간과 마지막을 담당한다. infrastructure 계층을 캡슐화하며, 영속 객체를 조회한다.

[rhakdnj]

객체의 연관관계(association)를 최소화하면 탐색이 단순해지는 이점이 있으나 현실 세계는 그렇게 호락호락하지 않다.

그래서 객체의 연관관계를 있는 그대로 표현하게 되면 시스템이 상당히 복잡해지게 된다.

이런 복잡한 관계의 객체들을 그대로 사용하지 않고 묶어서 경계(boundary)를 설정해 주면 이해하기가 더 수월해지는데 이렇게 묶인 단위들을 aggregate라고 할 수 있다.

[rhakdnj]

DB에서 Person 객체를 삭제한다고 가정해 보자.

이런 Person 객체는 보통 이름, 생년월일, 주소 등과 같은 속성을 갖는다. 시스템에서 Person을 삭제하면 이런 속성들도 자연스럽게 삭제된다.

하지만 주소의 경우 다른 Person 객체도 동일 주소를 참조하고 있다면 문제가 될 수 있다. 객체 변경의 범위를 명확히 하지 않으면 시스템이 커질 때 문제가 될 수 있다.

물론 DB의 rollback이나 lock과 같은 기술적인 해법을 통해 일관성을 보장해 줄 수 있지만 기본적인 이는 모델링 문제의 해법을 간과한 것이다.

그렇다면 FK가 걸려있는 테이블만 가지고 있으면 되는 것이 아닌가?

따라서 데이터 변경의 단위로 다루는 연관 객체의 묶음 즉 범위(boundary)가 필요하다. 이를 aggregate라고 하며 아래와 같은 특징을 갖는다.

• Aggregate는 Aggregate Root 와 Boundary가 존재한다.
• Boundary는 무엇이 포함되고 포함되지 않는지를 정의한다.
• Root은 하나만 존재하며, Aggregate 내의 특정 Entity이다.
• Boundary 내 객체는 서로 참조가 가능하며, 외부에서는 Root만 참조 가능하다.
• Root entity는 전역 식별성을 지니며, 이외의 entity는 지역 식별성을 지닌다.

[rhakdnj]

Aggregate를 구현할 때 위와 같은 트랜잭션에도 몇 가지 규칙이 적용된다.

• Root entity는 불변식을 검사해야 한다.
• Root entity는 내부 entity 참조를 다른 객체에 전달할 수 있지만 일시적으로만 사용 가능하다. VO를 전달할 때는 복사본을 전달한다.
• DB 질의를 이용하면 Aggregate Root만 직접적으로 획득하며, 다른 객체 참조는 Aggregate를 탐색해야 한다.
• 삭제 연산은 Aggregate 내의 모든 요소를 한 번에 제거해야 한다.
• Aggregate 내의 어떤 객체를 변경해도 전체 Aggregate의 불변식은 지켜져야 한다.