인프런 커뮤니티 질문&답변
작성한 질문수
도메인설계 관련 질문드립니다 !!
작성
·
1.3K
7
1) 애그리거트를 나누실때 어떤 기준으로 나누시는지 궁금합니다 !!
ex) 아이템,주문, 회원, 결제 이런식으로 도메인을 나누는 기준 더 나아가서 아이템에 대한 리뷰, 결제기록, 서비스쿠폰과 같이 애매한 도메인이 추가된다면 어떤식으로 나누어야할지 너무 헷갈립니다 ㅠㅠ
2) 애그리거트 루트를 참조할때는 객체를 통해 접근하면 각 애그리거트간의 결합도가 상승할거같은데 어떤식으로 처리하시나요 ??
ex) 아이템과 주문이 아예 다른패키지이거나 다른프로젝트 일경우 어떤식으로 해야하나요 ??
답변 3
15
안녕하세요. 윤성님
1) 애그리거트를 나누실때 어떤 기준으로 나누시는지 궁금합니다 !!
-> 우선 애그리거트는 우리가 생각하는 것 보다 훨씬 작은 단위로 만들어집니다. 애그리거트는 상황마다 다르기는 하지만, 엔티티 하나가 거의 하나의 애그리거트로 만들어집니다. 이정도로 작은 단위로 만들어야합니다.
아이템, 주문, 회원, 결제 이런식으로 도메인을 나누면 이것은 애그리거트보다 상위 개념인 BoundedContext 개념으로 나누어야 합니다.
2) 애그리거트 루트를 참조할때는 객체를 통해 접근하면 각 애그리거트간의 결합도가 상승할거같은데 어떤식으로 처리하시나요 ??
-> DDD에서는 주로 이런 경우 연관관계를 맺지 말고, 식별자로 분리하라고 설명합니다. 이렇게 하면 다른 프로젝트여도 해당 식별자(String id, Long Id 등등)만 가지고 있으면 되기 때문에, 문제가 없습니다.
그런데, 이 모든 것은 프로젝트의 규모에 따른 선택이 필요합니다. 애그러거트 개념을 통해서 애그리거트 단위로 트랜잭션을 만들고 전파하고, 이런 부분은 다른 방면의 복잡성을 매우 높입니다.
추가로 연관관계를 매핑할 때 참조값 대신에 식별자를 사용하는 방법 등은, 모두 좋아보이지만, 실무에서는 이렇게 하면 fetch join을 통한 성능 최적화가 어렵습니다.
DDD를 적용할 때는 모든 것을 적용한다기 보다는, DDD를 재대로 공부하고, 필요한 부분을 우리 프로젝트에 맞게 선택해서 가져오는 것이 맞는 방향이라 생각합니다.
JPA나 ORM을 처음 사용할 때는, 단순히 애그리거트 개념도 빼고, 도메인 이벤트 개념도 빼고, 연관관계는 모두 설정하는 방향으로 기본을 가져가는 것을 저는 권장합니다.
이후에 프로젝트가 커지면 점진적으로 이러한 개념을 도입하고 적용하는게 저는 더 맞다고 생각합니다^^
감사합니다.
0
애그리거트라는 것이 생각보다 작은 단위로 나오는 것이 맞다 생각합니다. 항상 그런 것은 아니지만 거의 하나의 엔티티가 하나의 애그리거트 단위가 되는 것으로 생각해주시면 됩니다.
물론 설계와 관련된 부분이라 상황마다 다르겠지만요 :)