작성한 질문수 32

3

안녕하세요. 진현님

DDD로 개발한다고 해서 그 안에 있는 모든 전략을 다 따라서 하는 것이 꼭 좋은 방법은 아닙니다.

모든 기술 선택에는 트레이드 오프가 있습니다.

지금처럼 모든 연관관계를 제거하게 되면 JPA에서 제공하는 fetch join같은 최적화 기술을 사용할 수 없습니다.

그래서 연관된 데이터를 함께 사용해야 할 때 쉽게 조회할 수 있는 기능도 아주 복잡하게 조립하거나 또는 DTO와 조인을 함께 사용해서 조회해야 합니다.

제가 권장하는 방법은 다음과 같습니다.

1. 프로젝트가 작고, JPA나 DDD같은 기술 사용 경험이 부족하다면 처음에는 연관관계를 적극적으로 사용합니다.

2. 프로젝트가 어느정도 규모가 있다면 큰 모듈 단위로 경계를 정하고 그 경계 안에서는 연관관계를 가지도록 하는 방법입니다. 예를 들면 회원, 주문, 결제 이 정도의 경계를 만들고, 그 안에서만 연관관계를 사용합니다. 이렇게 해두면 미래에 각각의 모듈을 마이크로서비스로 빼더라도 연관관계가 없기 때문에 상대적으로 쉽게 각 모듈을 분리할 수 있습니다.

3. 애그리거트를 도입하는 것은 최소한 2의 경험을 가진 분들이 도입하는 것이 좋습니다. 2의 각 모듈 안에서 애그리거트를 사용하는 방식이 더 적절한 모듈이 있고, 또는 애그리거트를 사용하지 않고 연관관계를 적극적으로 사용하는 것이 더 나은 모듈이 있습니다. 참고로 질문하신 것 처럼 애그리거트는 주로 테이블, 엔티티당 하나가 나오게 됩니다.

도움이 되셨길 바래요.

0

안녕하세요, 인프런 AI 인턴이에요.
답변드리겠습니다.

DDD에서는 애그리거트끼리의 관계를 맵핑하는 것을 지양하는 것이 맞습니다. 애그리거트 내부에서는 값을 변경할 수 있는 일관된 상태를 유지하는 것이 중요하기 때문입니다.

ERD 기준으로 도메인을 설계하고, 테이블 당 하나의 애그리거트가 나오는 것이 보편적인 사항은 아닙니다. 애그리거트는 하나 이상의 테이블을 포함할 수 있습니다. 예를 들어, 주문 애그리거트는 주문 테이블, 주문 상품 테이블, 상품 테이블을 포함할 수 있습니다.

따라서, 도메인 클래스에 관계를 맺는 부분이 없는 것이 보편적인 것도 아닙니다. 애그리거트 내부에서 필요에 따라 규칙에 따라 관계를 맺을 수 있습니다.

좀 더 자세한 내용은 DDD 책을 참고하시면 도움이 될 것입니다. 감사합니다.