도메인 주도 설계 구현
애그리게잇(aggregate)
규칙 : 경계의 밖에선 결과적 일관성을 사용하라
1 | 애그리게잇을 아우르는 규칙이 언제나 최신 상태로 유지되길 기대할 순 없다. |
하나의 애그리게잇 인스턴스에서 커맨드를 수행할 때 하나 이상의 애그리게잇에서 추가적인 비즈니스 규칙이 수행돼야 한다면 결과적 일관성을 사용하자
큰 규모의 트래픽이 많은 엔터프라이즈에선 애그리게잇 인스턴스가 절대적이고 완전하게 일관성을 유지할수 없다는 점을 받아 들인다면
결과적 일관성이 더 적은 인스턴스가 관련된 더 작은 규모에서도 의미가 있다는 사실을 좀 더 쉽게 이해할 수 있다.
도메인 전문가는 일관성을 달설할때 까지 합리적인 지연을 허용할 의지가 있다.(이미 자동화가 적용되기전에 지연이 존재했음)
누가 해야 하는 일인지 확인하자
트랜젝션 일관성을 사용할지 결과적 일관성을 사용할지 선택은 어렵다.
만약 다른 사용자나 시스템이 해야 할일이라면 결과적 일관성을 사용자가 하는일이라면 트랜잭션 일관성을 사용하자
규칙을 어겨야 하는 이유
- 사용자 인터페이스의 편의
- 기술적 메커니즘의 부족
- 글로벌 트랜젝션
- 쿼리 성능
발견을 통해 통찰 얻기
- 설계를 다시 한번 생각해보자
- 애그리게잇 비용의 예측
- 일반적인 사용 시나리오
- 메모리 소비
- 결과적 일관성의 구현
구현
고유 ID와 루트 엔터티를 생성하라
하나의 엔터티를 애그리게잇 루트로 모델링하라
값 객체 파트를 선호하라
가능하다면 포함된 애그리게잇 파트를 엔터티보다는 값 객체로서 모델링하는 편을 선택하자
데메테르 법칙과 묻지 말고 시켜라를 사용하기
데메테르의 법칙 : 이 원칙은 최소 지식의 원칙을 강조한다. 모든 객체의 모든 메소드는 다음을 통해서만 메소드를 호출해야 된다. 1) 그자신, 2) 자신에게 전달된 매개변수,
3) 자신이 인스턴스화하는 객체, 4) 자신이 직접 엑세스할 수 있는 스스로가 포함된 파트 객체
묻지 말고 시켜라 : 이 원칙은 단순히 객체에게 할 일을 알려줘야 한다는 점을 강조하고 있다.
낙관적 동시성
version 특성을 어디에 위치시켜야 하는지 생각해봐야 한다.
의존성 주입을 피하라
일반적으로 리파지토리나 도메인 서비스의 애그리게잇으로서의 의존성 주입은 나쁘다고 볼 수 있다.