도메인 주도 설계 구현
애그리게잇(aggregate)
스크럼 핵심 도메인에서 애그리게잇 사용하기
큰 클러스터의 애그리게잇
크기가 큰 애그리게잇은 처음엔 그럴싸해 보이지만 실제론 실용적이지 않다.
의도치 않게 트랜젝션이 주기적으로 실패하는데
실패의 원인은 실제 비즈니스 규칙이 아닌 잘못된 고정자를 기준으로 설계 하여 실패
다수의 애그리게잇
애그리게잇을 작개 나누어서 해당 내용을 밖으로 빼서 트랜젝션 실패 문제를 해결 하는 방법도 있다.
규칙 : 진짜 고정자를 일관성 경계 안에 모델링하라
고정자(invariant)는 언제나 일관성을 유지해야만 한다는 비즈니스 규칙이다.
일관성에는 여러종류가 있는데 트랜잭션적 일관성, 결과적 일관성 등이 있다.
고정자에 관한 논의는 트랜잭션적 일관성과 관련이 있다.
일관성 경계는 어떤 오퍼레이션이 수행되든 상관없이 경계 안의
모든 대상이 특정 비즈니스 고정자 규칙 집합을 준수하도록 논리적으로 보장해준다.
이 경계 밖에 일관성은 애그리게잇과 무관하다.
전형적인 영속성 메커니즘을 사용하면 단일 트랜잭션을 사용해 일관성을 관리한다.
트랜잭션이 커밋하는 시점에서 하나의 경계 안에 속한 모든 것이 반드시 일관성을 유지해야 한다.
바르게 설계된 바운디드 컨텍스트는 어떤 상황에서든 한 트랜젝션당 한 애그리게잇 인스턴스만을 수정한다.
애그리게잇이 일관성을 초점에 두고 설계돼야 한다는 사실은
사용자 인터페이스는 단 하나의 애그리게잇 인스턴스상에서만 수행되도록 매요청마다 집중해야 함을 의미한다.
그러므로 애그리게잇은 주로 일관성 경계와 관련이 있으며 객체 그래프를 설계할려는 의도 와는 상관이 없다.
규칙 : 작은 애그리게잇으로 설계하라
큰 클러스터 애그리게잇은 성능이나 확장성이 좋지 못하다.트랜잭션의 성공적 종료, 성능, 확장성의 측면에서 안 좋은 영향을 미친다.
작은 애그리게잇을 설계 할때 작다는 단어는 어떤 수준을 의미할까?
애그리게잇을 루트 엔터티와 최소한의 특성이나 값 타입을 속성으로 제한하자.
정확히 필요한 만큼 담고 그이상도 그 이하도 아니어야 한다.
크기가 작은 애그리게잇은 성능과 확장성이 더 좋을 뿐 아니라 커밋을 가로막는 문제가 거의 일어나지 않기 때문에
트랜잭션이 성공할 가능성이 높다.
유스케이스를 전부 믿지는 말라.
여러 애그리게잇 인스턴스 사이의 일관성을 유지하려는 노력은 여러분의 팀이 고정자를 놓치고 있다는 의미일 수도 있다.
규칙 : ID로 다른 애그리게잇을 참조하라
애그리게잇을 설계하면서 객체 그래프를 깊이 탐색하는 컴포지션 구조를 원할수도 있겠지만 이는 패턴이 의도한 바가 아니다.
애그리게잇이 다른 애그리게잇 루트로의 참조를 가질수 있다고 했지만
이는 참조된 애그리게잇을 참조하고 있는 애그리게잇의 일관성 경계 안쪽으로 위치시킨다는 의미가 아니다라는 사실을 기억해야 한다.
애그리 게잇이 ID 참조를 통해 서로 함께 동작하도록 해보자
추론 객체 참조를 가진 애그리게잇은 참조를 즉시 가져올 필요가 없기 때문에 더 작아 진다.
ID를 통한 참조를 사용한다고 모델을 전혀 탐색할수 없는것은 아니다.
조회를 위해 애그리게잇 내부에서 리파지토리를 사용할수도 있고 애그리게잇의 메소드를 호출하기 앞서
리파지토리나 도메인 서비스를 통해 의존 관계에 있는 객체를 조회하는 방법도 추천할 만하다.
애플리케이션 서비스가 의존성을 풀어내면 애그리게잇은 리파지토리나 도메인 서비스에 의지할 필요가 없어진다.
쿼리 성능에 문제가 발생한다면 세타조인이나 CQRS의 사용도 고려해볼 만하다.
분산된 시스템에 걸친 트랜잭션은 원자적이지 않다 많은 시스템에선 여러 애그리게잇이 결과적 일관성을 달성하도록 하고 있다.