인프런 커뮤니티 질문&답변
작성한 질문수
격벽의 의미
해결된 질문
작성
·
32
1
안녕하세요! 격벽은 주요 개념을 나누고 가능한 직접 의존하지 않게 하는 판단 기준이라고 생각이 들었습니다!
그런데 예를 들어 복잡한 조회 쿼리의 경우에는 컨트롤러단에서 각 개념 간 조회를 하고 이를 어플리케이션 단에서 데이터를 필터링하는 것보다 join을 하는 경우가 성능적으로나 구현적으로 나은 방식이 될 수 있을 거 같습니다!
이런 경우 서로 다른 두 개념이 있을 때 한 개념 내 테이블과 다른 개념 내 테이블을 직접 join하는 경우가 있을 거 같은데요, 혹시 이런 경우도 가능한 지양하시는 편이실까요?? 벽을 침범하지 않는다는 것이 이런 경우에도 적용되어야 하는 것인지 궁금합니다!
답변 1
1
안녕하세요! 아주 좋은 질문 감사드립니다!
말씀해주신 것 처럼 Join 을 통해서 문제를 푸는 경우가 더 성능적과 구현상 효과적인 경우가 있습니다
(저희 쿠폰 예제에서도 Join 코드와 Join 안쓴 코드가 공존하게 해두었습니다 ㅎㅎ)
저는 기본적으로는 Join을 쓰게 된다면 Join 자체가 격벽을 침범한다고 가정하고, 그 기준을 적절히 유지하기위해 Join 하는 테이블들도 응집 기준으로 쓰는 편입니다
이게 왜 중요하다 생각하냐면 Join을 쓰는 것 자체는 문제가 아니지만 이것이 격벽을 침범하지 않는다 가정하면 한방에 모든걸 해결하는 God Query가 탄생하게 됩니다.
(느낌 오시겠지만 이건 정말 어마어마한 레거시가 되버립니다 ㅜㅜ)
그렇기 때문에 격벽을 침범한다 가정하고 관리한다면, 비교적 규모가 있는 Join 쿼리를 조합하여 성능과 구현 이점을 누리면서도 소프트웨어의 구현 수준을 떨어트리지 않게 됩니다
OwnedCouponService.getOwnedCouponsForCheckout 코드를 한번 참고해보시면 제거 어떤식으로 묶어서 쿼리를 구성하고 조합하는지 느낌을 보실 수 있을 것 같습니다!
(참고로 저 코드의 CouponRepository.findApplicableCouponIds Join 쿼리와 CouponService.getCouponsForProducts 코드 동작은 완벽히 일치합니다, 즉 Join 쓰는 방식 / 안쓰는 방식의 차이도 여기서 보실 수 있을 것 같습니다, 확실히 Join 을 쓰는게 코드가 간결해지는 부분이 있긴합니다ㅎㅎ)
모쪼록 답이 되었길 바랍니다! 감사합니다!