도메인 주도 개발 시작하기(3)
3-1. 애그리거트
•
도메인 객체 모델이 복잡해지면 개별 구성요소 위주로 모델을 이해하게 되고 전반적인 구조나 큰 수준에서 도메인 간의 관계를 파악하기 어려워진다
◦
주요 도메인 요소 간의 관계를 팡가하기 어렵다는 것은 코드를 변경하고 확장하는 것이 어려워진다는 것을 의미한다
•
복잡한 도메인을 이해하고 관리하기 쉬운 단위로 만들려면 상위 수준에서 모델을 조망할 수 있는 방법이 필요한데, 그 방법이 바로 애그리거트다
◦
수많은 객체를 애그리거트로 묶어서 바라보면 상위 수준에서 도메인 모델 간의 관계를 파악할 수 있다
◦
애그리거트는 모델을 이해하는 데 도움을 줄 뿐만 아니라 일관성을 관리하는 기준도 된다
•
한 애그리거트에 속한 객체는 다른 애그리거트에 속하지 않는다.
◦
애그리거트는 독립된 객체 군이며, 각 애그리거트는 자기 자신을 관리할 뿐 다른 애그리거트를 관리하지 않는다
•
경계를 설정할 때 기본이 되는 것은 도메인 규칙과 요구사항이다
◦
도메인 규첵에 따라 함께 생성되는 구성요소는 한 애그리거트에 속할 가능성이 높다
•
처음 도메인 모델을 만들기 시작하면 큰 애그리거트로 보이는 것들이 많지만, 도메인에 대한 경험이 생기고 도메인 규칙을 제대로 이해할수록 애그리거트의 실제 크기는 줄어든다
◦
대개 다수의 애그리거트가 한 개의 엔티티 객체만 갖는 경우가 많으며, 두 개 이상의 엔티티로 구성되는 애그리거트는 드물었다
3-2. 애그리거트 루트
•
애그리거트는 여러 객체로 구성되기 때문에 한 객체만 상태가 정상이면 안된다
◦
도메인 규칙을 지키려면 애그리거트에 속한 모든 객체가 정상 상태를 가져야 한다
e.g
•
애그리거트에 속한 모든 객체가 일관된 상태를 유지하려면 애그리거트 전체를 관리할 주체가 필요한데, 이 책임을 지는 것이 바로 애그리거트의 루트 엔티티다
◦
애그리거트에 속한 객체는 애그리거트 루트 엔티티에 직간접적으로 속하게 된다
3-2-1. 도메인 규칙과 일관성
•
애그리거트 루트의 핵심 역할은 애그리거트의 일관성이 깨지지 않도록 하는것이다
•
애그리거트 외부에서 애그리거트에 속한 객체를 직접 변경하면 안된다
◦
애그리거트 루트가 강제하는 규칙을 적용할 수 없어 모델의 일관성을 깨는 원인이 된다
•
불필요한 중복을 피하고 애그리거트 루트를 통해서만 도메인 로직을 구현하게 만들려면 도메인 모델에 대해 두 가지를 습관적으로 적용해야 한다
1.
단순히 필드를 변경하는 set 메소드를 공개 범위로 만들지 않는다
2.
Value 타입은 불변으로 구현한다
3-2-2. 애그리거트 루트의 기능 구현
•
애그리거트 루트는 애그리거트 내부의 다른 객체를 조합해서 기능을 완성한다
•
애그리거트 루트가 구성요소의 상태만 참조하는 것은 아니며, 기능 실행을 위임하기도 한다
예시 코드
•
보통 한 애그리거트에 속하는 모델은 한 패키지에 속하기 때문에 패키지나 protected 범위를 사용하면 애그리거트 외부에서 상태 변경 기능 실행하는 것을 방지할 수 있다
3-2-3. 트랜잭션 범위
•
트랜잭션 범위는 작을수록 좋다
◦
잠금 대상이 많아진다는 것은 그만큼 동시에 처리할 수 있는 트랜잭션 개수가 줄어든다는 것을 의미하고, 이것은 전체적인 성능(처리량)을 떨어뜨린다
•
한 트랜잭션에서는 한 개의 애그리거트만 수정해야 한다
◦
한 트랜잭션에서 두 개 이상의 애그리거트를 수정하면 트랜잭션 충돌이 발생할 가능성이 더 높아지기 때문에 한 번에 수정하는 애그리거트 개수가 많아질수록 전체 처리양이 떨어진다
•
애그리거트에서 다른 애그리거트를 변경하지 않아야 한다
◦
애그리거트는 최대한 독립적이어야 하는데, 한 애그리거트가 다른 애그리거트의 기능에 의존하기 시작하면 애그리거트 간 결합도가 높아진다
예시 코드
◦
도메인 이벤트를 사용하면 한 트랜잭션에서 한 개의 애그리거트를 수정하면서도 동기나 비동기로 다른 애그리거트의 상태를 변경하는 코드를 작성할 수 있다
•
일부 상황에서 한 트랜잭션에서 두 개의 애그리거트를 변경하는 것을 고려할 수 있다
1.
팀 표준
•
팀이나 조직의 표준에 따라 사용자 유스케이스와 관련된 응용 서비스의 기능을 한 트랜잭션으로 실행해야 하는 경우
2.
기술 제약
•
기술적으로 이벤트 방식을 도입할 수 없는 경우 한 트랜잭션에서 다수의 애그리거트를 수정해서 일관성을 처리
3.
UI 구현의 편리
•
운영자의 편리함을 위해 주문 목록 화면에서 여러 주문의 상태를 한 번에 변경하고 싶을 때
3-3. 리포지터리와 애그리거트
•
객체의 영속성을 처리하는 리포지터리는 애그리거트 단위로 존재한다
◦
예시
▪
Order 와 OrderLine 을 물리적으로 각각 별도의 DB 테이블에 저장한다고 해서 Order 와 OrderLine 을 위한 리포지터리를 각각 만들지 않는다
▪
Order 가 애그리거트 루트고, OrderLine 은 애그리거트에 속하는 구성요소이므로 Order 를 위한 리포지터리만 존재한다
•
리포지터리는 보통 두 메소드를 기본으로 제공한다
◦
save: 애그리거트 저장
◦
findById: ID 로 애그리거트를 구함
◦
이 두 메소드 외에 필요에 따라 다양한 조건으로 애그리거트를 검색하는 메소드나 애그리거트를 삭제하는 메소드를 추가할 수 있다
•
애그리거트는 개념적으로 하나이므로 리포지터리는 애그리거트 전체를 저장소에 영속화해야 한다
•
애그리거트를 구하는 리포지터리 메소드는 완전한 애그리거트를 제공해야 한다
•
애그리거트를 영속화할 저장소로 무엇을 사용하든지 간에 애그리거트의 상태가 변경되면 모든 변경을 원자적으로 저장소에 반영해야 한다
3-4. ID를 이용한 애그리거트 참조
•
한 객체가 다른 객체를 참조하는 것처럼, 애그리거트도 다른 애그리거트를 참조한다
◦
애그리거트 관리 주체는 애그리거트 루트이므로, 애그리거트에서 다른 애그리거트를 참조한다는 것은 다른 애그리거트의 루트를 참조하는 것과 같다
•
필드를 이용해서 다른 애그리거트를 직접 참조하는것은 개발자에게 구현의 편리함을 제공하지만, 여러 문제점이 있다
예시 코드
1.
편리함을 오용할 수 있다
2.
애그리거트를 직접 참조하면 성능과 관련된 여러가지 고민을 해야 한다
•
JPA 를 사용하면 참조한 객체를 lazy loading, eager loading 두 가지 방식으로 로딩할 수 있다
•
다양한 경우의 수를 고려해서 연관 매핑과 JPQL/Criteria 쿼리의 로딩 전략을 결정해야 한다
3.
확장에 문제가 발생한다
•
초기에는 단일 DBMS 로 서비스를 제공하는 것이 가능하지만, 사용자가 많아지면서 부하를 분산하기 위해 하위 도메인별로 시스템을 분리하기 시작한다
◦
이 과정에서 도메인마다 서로 다른 DBMS 를 사용할 때도 있다
•
더이상 다른 애그리거트 루트를 참조하기 위해 JPA 와 같은 단일 기술을 사용할 수 없다
•
이런 문제점들을 해결하기 위해서 사용하는 것이 ID 를 이용해서 다른 애그리거트를 참조하는 것이다
예시 코드
•
ID 참조를 사용하면 모든 객체가 참조로 연결되지 않고, 한 애그리거트에 속한 객체들만 참조로 연결된다
◦
애그리거트의 경계를 명확히하고, 애그리거트간의 물리적인 연결을 제거해서 모델의 복잡도를 낮춰준다
◦
애그리거트간의 의존을 제거하므로 응집도를 높여주는 효과도 있다
◦
구현 복잡도도 낮아진다
3-4-1. ID를 이용한 참조와 조회 성능
N+1 조회 문제란?
조회 대상이 N개 일 때 N개를 읽어오는 한번의 쿼리와 연관된 데이터를 읽어오는 쿼리를 N번 실행한다.
•
다른 애그리거트를 ID 로 참조하면 참조하는 여러 애그리거트를 읽을 때 조회 속도가 문제될 수 있다
◦
대표적인 문제가 N+1 조회 문제이다
◦
N+1 조회 문제는 더 많은 쿼리를 실행하기 때문에 전체 조회 속도가 느려지는 원인이 된다
•
ID 참조 방식을 사용하면서 N+1 조회와 같은 문제가 발생하지 않도록 하려면 조회 전용 쿼리를 사용하면 된다
•
애그리거트마다 서로 다른 저장소를 사용하면 한 번의 쿼리로 관련 애그리거트를 조회할 수 없다
◦
이 때는 조회 성능을 높이기 위해 캐시를 적용하거나, 조회 전용 저장소를 따로 구성한다
◦
장점
▪
시스템의 처리량을 높일 수 있다
◦
단점
▪
코드가 복잡해진다
3-5. 애그리터그 간 집합 연관
•
애그리거트 간 1:N 관계는 Set 과 같은 컬렉션을 이용해서 표현할 수 있다
◦
개념적으로는 애그리거트 간에 1:N 관계가 있더라도 성능 문제 때문에 애그리거트 간의 N:1 구조로 개발할 수 있다
예시 코드
•
M:N 관계는 개념적으로 양쪽 애그리거트에 컬렉션으로 연관을 만든다
◦
1:N 관계처럼 M:N 관계도 실제 요구사항을 고려하여 M:N 연관을 구현에 포함시킬지를 결정한다
예시 코드
3-6. 애그리거트를 팩토리로 사용하기
•
애그리거트가 갖고 있는 데이터를 활용해서 다른 애그리거트를 생성해야 한다면 애그리거트에 팩토리 메소드를 구현하는 것을 고려하는게 좋다
예시 코드
•
애그리거트를 생성할 때 많은 정보를 알아야 한다면 다른 팩토리에 위임하는 방법도 있다
예시 코드