인프런 커뮤니티 질문&답변
작성한 질문수
JPA> DDD 서로 다른 애그리거트 사이의 간접참조
작성
·
893
0
안녕하세요 영한님! 프로젝트에 JPA 및 DDD를 적용하며 의문점이 생기는 부분이 있는데 물어볼 곳이 마땅치 않아서, 이렇게 질문글 올립니다.
구조(요약) - 모노리틱
저희 프로젝트에서 다음과 같이 서로 다른 애그리거트 사이에는 간접참조를 통해 느슨하게 결합하여 사용하고 있습니다.
질문
다음과 같이 설정하고 나니 몇 가지 의문점이 있습니다.
간접 참조를 통해 느슨한 결합을 하고 있는데, DB 에 따로 외래키 제약 조건을 걸어주어야하는가?
이 부분에 있어서 팀원과 의견이 달라서요. 저는 애그리거트를 나눈 목적이 결국 복잡도를 줄이기 위해서이고, 각각의 애그리거트 안에서 트랜잭션으로 관리가 되어야한다고 생각을 하는데.. 외래키를 설정하면 결국은 User 를 관리할 때 참조 무결성을 신경쓰면서 Trip 까지 고려를 해야돼서 좋지 않다고 생각합니다. 굳이 DB에서 외래키 제약을 걸지 않아도 이벤트를 통해 관리할 수 있다고 생각을 하기도 하구요.
팀원분은 어플리케이션보다는 변경점이 낮은 DB를 우선으로 하며 개발을 해야하고, 그렇기 때문에 반드시 외래키를 걸어주어야한다고 말씀하시는데, 무엇이 더 맞는 말인지 잘 모르겠습니다.회원 탈퇴(User 삭제)가 이루어질 때 회원과 관련된 모든 Trip 삭제(벌크성 삭제 쿼리)가 이루어지도록 하기 위해서 이벤트를 활용하고 있는데, 이를 비동기적으로 처리해도 문제가 되지 않는가?
@Async, @TransactionalEventListener 를 활용해서 회원탈퇴 요청시 회원 삭제가 커밋이 완료 되면 회원이 작성한 여행 정보를 지우는 비동기 이벤트를 발행하도록 하고 있습니다. 회원 탈퇴시 중요한건 회원 정보를 삭제하는 것이라고 생각해서 이를 비동기적으로 처리하는게 옳다고 생각해서 이렇게 구현했는데, 이 방식이 옳은 방식인지 확신이 서질 않습니다. 현업에서는 어떻게 이런 문제를 해결하고 있는지 궁금합니다!
읽어주셔서 감사합니다!
답변 2
2
안녕하세요, 인프런 AI 인턴이에요. JPA와 DDD를 적용하며 의문이 생긴 부분에 대해 여쭙고 계신 건가요?
먼저 간접 참조를 통해 느슨한 결합을 하고 있을 때, DB에 외래키 제약 조건을 걸어주어야 하는지에 대한 의견이 달라서 질문하고 계신 거죠. 애그리거트를 나눈 목적은 복잡도를 줄이기 위해서이고, 각각의 애그리거트 안에서 트랜잭션으로 관리되어야 한다고 생각하시는군요. 외래키를 설정하면 User를 관리할 때 참조 무결성을 신경 써야하며, Trip까지 고려해야하기 때문에 좋지 않다고 생각하시는 거군요. DB에서 외래키 제약을 걸지 않고 이벤트를 통해 관리할 수 있다고 느끼시는군요. 그러나 팀원분은 어플리케이션보다는 변동성이 낮은 DB를 우선으로 해야하며, 그래서 반드시 외래키를 걸어주어야 한다고 말씀하신 거군요.
결론적으로는 DB에 외래키 제약을 걸어주어야 하는지에 대해서는 개발 팀에 따라 다를 수 있습니다. 일반적으로 DDD에서는 도메인 모델의 일관성을 유지하기 위해 외래키 제약을 걸지 않는 경향이 있습니다. 여기서는 애그리거트 간의 일관성을 유지하기 위해 간접 참조를 사용하고 계신 것으로 이해했습니다. 이를 위해 Event를 통해 관리해도 무방하다고 생각하시는 것 같네요.
다만, 외래키 제약을 걸지 않을 경우, 데이터베이스 관점에서 참조 무결성에 대한 책임을 도메인 레벨로 이동시키는 것이기 때문에, 개발 팀 및 프로젝트에 따라 적합한 방식을 선택하는 것이 중요합니다. 이 점을 팀원들과 충분한 협의 후 결정하시는 것이 좋을 것 같아요.
더 자세한 정보를 원하신다면 DDD와 JPA에 대한 관련된 자료를 참고하시는 것도 좋을 것 같습니다. 혹시라도 DDD와 JPA에 관련된 질문이 더 있으시다면 언제든지 물어보세요! 좋은 결과를 얻을 수 있기를 바라요. 감사합니다!
1
안녕하세요. 김규성님
AI가 답변을 잘 남겨주었네요. 몇가지 더하자면 회원 탈퇴의 경우 비동기적으로 처리하는 것이 좋은 방법이라 생각합니다. 다만 이 경우 챙겨야 하는 것들이 동기적으로 처리하는 것 보다 많기 때문에, 예를들어 트랜잭션 처리에서 중간에 문제가 발생하면 이벤트를 다시 발행해야 하는 등 실제 적용해보면 복잡한 상황에 놓이게 됩니다.
결국 애플리케이션 아키텍처의 선택은 모두 트레이드 오프가 있습니다.
제가 추천하는 방법은 처음에는 쉽고 단순하게 개발하고, 애플리케이션이 점점 커져서 복잡해지고 또 성능의 관점이 중요해지면 그때 필요한 부분들을 점진적으로 개선하는 것도 좋은 방향이라 생각합니다.
감사합니다.
답변 감사합니다! 매번 좋은 강의 덕에 많이 배우고 있습니다 :)