도메인주도개발 시작하기 3장
- 백 개 이상의 테이블을 한장의 ERD에 모두 표시하면 개별 테이블 간의 관게를 파악하느라 큰 틀에서 데이터 구조를 이해하는데 어려움을 겪음
- 도메인 객체 모델이 복잡해지면 개별 구성요소 위주로 모델을 이해하게 되고 전반적인 구조ㅗ나 큰 수준에서 도메인 간의 관계를 파악하기 어려워진다
- 애그리거트는 모델을 이해하는 데 도움을 줄 뿐만 아니라 일관성을 관리하는 기준도 된다.
- 모델을 보다 더 잘 이해할 수 있고 애그리거트 단위로 일관성을 관리하기 때문에, 애그리거트는 복잡한 도메인을 단순한 구조로
만들어 준다.
- 복잡도가 낮아지는 만큼 도메인 기능을 확장하고 변경하는데 필요한 노력(개발시간)도 줄어든다
- 애그리거트는 관련된 모델을 하나로 모았기 때문에 한 애그리거트에 속한 객체는 유사하거나 동일한 라이프 사이클을 갖는다.
- 대부분은 애그리거트에 속한 구성요소는 대부분은 함께 생성하고 함께 제거한다.
- 애그리거트는 경계를 갖는다.
- 한 애그리거트에 속한 객체는 다른 애그리거트에 속하지않는다
- 대개 한 애그리거트는 한 개의 엔티티 객체만 갖는 경우가 많음
애그리거트 루트
도메인 규칙을 지키려면 애그리거트에 속한 모든 객체가 정상 상태를 가져야한다. 그렇지않으면 nullpointexception이 뜰 수 있다.
루트 엔티티 :
애그리거트의 대표 엔티티, 애그리거트에 속한 모든 객체가 일관된 상태를 유지하기 위한 애그리거트 전체를 관리한 주체
- 애그리거트 루트의 핵심 역할은 애그리거트의 일관성이 깨지지 않도록 하는 것
- 이를 위해 루트는 애그리거트가 제공해야 할 도메인 기능을 구현
불필요한 중복을 피하고 애그리거트 루트를 통해서만 도메인 로직을 구현하기 위한 방법
1. 단순히 필드를 변경하는 set 메서드를 public 범위로 만들지 않기
2. 벨류 타입은 불변으로 구현
- 팀 표준이나 기술 제약으로 불변으로 구현할 수 없다면 패키지나 protected 범위로 한정해서
외부에서 실행할 수 없도록 제한할 수도 있음
- 한 트랜젝션에서는 한 개의 애그리거트만 수행, 애그리거트에서 다른 에그리거트를 변경하지 않음
- 애그리거트는 최대한 서로 독립적이어야. 한 애그리거트가 다른 애그리거트의 기능에 의존하기 시작하면 애그리거트 간 결합도 높아짐
- 부득이하게 두 개 이상 애그리거트를 수정해야 한다면 응용 서비스에서 두 애그리거트를 수정하도록 구현
- 한 트랜잭션에서 한 개의 애그러거트를 변경하는 것을 권장하지만, 다음과 같은 경우에는 한 트랜잭션에서 두개 이상의
애그리거트를 변경하는 것을 고려할 수 있다.
1. 팀표준: 팀이나 조직의 표준에 따라 사용자 유스케이스와 관련된 응용서비스의 기능을 한 트랜잭션으로 실행해야 하는 경우가 있다.
2. 기술제약: 기술적으로 이벤트 방식을 도입할 수 없는 경우 한 트랜잭션에서 다수의 애그리거트를 수정해서 일관성을 처리해야한다.
3. UI구현의 편리: 운영자의 편리함을 위해 주문 목록 화면에서 여러 주문의 상태를 한번에 변경하고 싶을 것이다. 이 경우 한 트랜잭션에서 여러 주문 애그리거트의 상태를 변경해야 한다.
리포지터리와 애그리거트
리포지터리는 애그리거트 단위로 존재
한 어그리거트를 저장할 때 어그리거트 루트와 모든 구성요소에 매핑되는 테이블에 데이터를 저장한다.
예를 들어 Order 애그리거트와 관련된 테이블이 세 개라면 Order 어그리거트를 저장할 때 어그리거트 루트와
매핑되는 테이블뿐만 아니라 애그리거트와 속한 모든 구성요소에 매핑된 테이블에 데이터를 저장해야한다.
주의사항: 리포지터리가 완전한 애그리거트를 제공하지 않으면 필드나 값이 올바르지 않아 애그리거트의 기능을 싱행하는 도중에
NullPointerException과 같은 문제가 발생할 수 있다.
ID를 이용한 애그리거트 참조
애그리거트에서 다른 애그리거트를 참조한다는 것은 다른 애그리거트의 루트를 참조한다는 것과 같음.
ID 참조를 사용하면 모든 객체가 참조로 연결되지 않고 한 애그리거트에 속한 객체들만 참조로 연결된다. 이는
애그리거트의 경계를 명확히 하고 애그리거트 간 물리적인 연결을 제거하기 때문에 모델의 복잡도를 낮춰준다.
또한 애그리거트 간의 의존을 제거하므로 응집도를 높여주는 효과가 있다.
애그리거트 직접 참조 문제점:
1. 편리함을 오용할 수 있다는 문제가 있음. 한 애그리거트가 자기 자신으로 한정해서 관리해야
2. 성능 측면 고민 필요. JPA를 사용시 지연-즉시로딩 방식 등 다양한 경우의 수 고려
3. 확장 측면에서도 문제. JPA를 사용하면 단일 기술만 사용해야
4.한 애그리거트 내부에서 다른 애그리거트 객체에 접근할 수 있으면 다른 애그리거트의 상태를 쉽게 변경할 수 있게 된다.
위 세 가지 문제를 완화하는 방법이 ID를 이용한 다른 애그리거트를 참조하는 것
- ID 참조를 사용하면 모든 객체가 참조로 연결되지 않고 한 애그리거트에 속한 객체들만 참조로 연결됨
- ID 참조 방식을 사용하면 N+1 조회 문제가 발생할 수 있음. 조회 전용 쿼리를 만들어 join을 사용해서 로딩 진행
- ID 참조 방식을 사용하면서 N+1 조회와 같은 문제가 발생하지 않도록 하려면 조회 전용 쿼리를 사용해야한다.
예를 들어 데이터 조회를 위한 별도의 DAO를 만들고 DAO의 조회 메서드에 조인을 이용하여 필요한 데이터를 한꺼번에 로딩시키면 된다.
- 즉시로딩이나 지연로딩과 같은 로딩전략을 고민할 필요없이 조회화면에서 필요한 애그리거트 데이터를 한번에 쿼리로
로딩할 수 있다. 쿼리가 복잡해지거나 SQL에 특화도니 기능을 사용해야한다면 조회를 위한 부분만 mybatis를 사용하여 구현할 수 있다.
즉, 다른 어그리거트를 참조해야할 경우 해당하는 아이디를 삽입하여 의존도를 떨어뜨려라
애그리거트 간 집합 연관
- 개념적ㅇ로는 애그리거트 간 1-N 연관이 있더라도 성능 문제 때문에 실제구현에는 반영하지않는다. 차라리 역으로
N-1로 연관지어 구현한다.
애그리거트를 팩토리로 사용하기
Service 단에서 Product 생성 판단 로직과 생성 로직을 각기 호출하고 있음
Store라는 Product를 만드는 팩토리를 구현하여 생성에 대한 책입은 팩토리로 이전
애그리거트가 갖고 있는 데이터를 이용해서 다른 애그리거트를 생성해야 한다면 애그리거트에 팩토리 메서드를 구현하는 것도 좋은 방법