격벽의 의미
안녕하세요! 격벽은 주요 개념을 나누고 가능한 직접 의존하지 않게 하는 판단 기준이라고 생각이 들었습니다!
그런데 예를 들어 복잡한 조회 쿼리의 경우에는 컨트롤러단에서 각 개념 간 조회를 하고 이를 어플리케이션 단에서 데이터를 필터링하는 것보다 join을 하는 경우가 성능적으로나 구현적으로 나은 방식이 될 수 있을 거 같습니다!
이런 경우 서로 다른 두 개념이 있을 때 한 개념 내 테이블과 다른 개념 내 테이블을 직접 join하는 경우가 있을 거 같은데요, 혹시 이런 경우도 가능한 지양하시는 편이실까요?? 벽을 침범하지 않는다는 것이 이런 경우에도 적용되어야 하는 것인지 궁금합니다!
답변 1
3
안녕하세요! 아주 좋은 질문 감사드립니다!
말씀해주신 것 처럼 Join 을 통해서 문제를 푸는 경우가 더 성능적과 구현상 효과적인 경우가 있습니다
(저희 쿠폰 예제에서도 Join 코드와 Join 안쓴 코드가 공존하게 해두었습니다 ㅎㅎ)
저는 기본적으로는 Join을 쓰게 된다면 Join 자체가 격벽을 침범한다고 가정하고, 그 기준을 적절히 유지하기위해 Join 하는 테이블들도 응집 기준으로 쓰는 편입니다
이게 왜 중요하다 생각하냐면 Join을 쓰는 것 자체는 문제가 아니지만 이것이 격벽을 침범하지 않는다 가정하면 한방에 모든걸 해결하는 God Query가 탄생하게 됩니다.
(느낌 오시겠지만 이건 정말 어마어마한 레거시가 되버립니다 ㅜㅜ)
그렇기 때문에 격벽을 침범한다 가정하고 관리한다면, 비교적 규모가 있는 Join 쿼리를 조합하여 성능과 구현 이점을 누리면서도 소프트웨어의 구현 수준을 떨어트리지 않게 됩니다
OwnedCouponService.getOwnedCouponsForCheckout 코드를 한번 참고해보시면 제거 어떤식으로 묶어서 쿼리를 구성하고 조합하는지 느낌을 보실 수 있을 것 같습니다!
(참고로 저 코드의 CouponRepository.findApplicableCouponIds Join 쿼리와 CouponService.getCouponsForProducts 코드 동작은 완벽히 일치합니다, 즉 Join 쓰는 방식 / 안쓰는 방식의 차이도 여기서 보실 수 있을 것 같습니다, 확실히 Join 을 쓰는게 코드가 간결해지는 부분이 있긴합니다ㅎㅎ)
모쪼록 답이 되었길 바랍니다! 감사합니다!
궁금한점이 여러개 생겼습니다.
1
38
1
다양한 관점의 코드 경험을 위해 개선하지 않은 코드
1
55
1
histories() 응답에 PointHistory.id를 포함한 이유가 궁금합니다/
1
44
2
SettlementTargetRepository Jquery 질문
1
48
2
부가 기능을 이벤트 핸들러로 분리하는 기준이 있을까요?
1
60
2
엔티티의 pk 를 0으로 초기화하시는 이유가 있을까요??
1
67
2
제미니님 안녕하세요!
1
77
2
개념 간 격벽 분리와 목록 조회 시 발생하는 참조 구조
1
85
2
프로덕트와 프로덕트카테고리 사이의 삭제 정책
1
76
2
새로 개발한다면 구현 순서
1
136
1
의존 방향에 대한 고민
1
125
2
어드민(Back-office)에서 예약 변경 시, '할인 조건 재검증(쿠폰 회수)' vs '기존 혜택 유지' 중 어떤 정책이 일반적인가요?
1
98
2
OrderKeyGenerator 인스턴스화 generate() 질문
1
84
1
외부 API 통합 시 데이터 제어 범위 설계 질문
1
98
1
PG 결제 승인 로직
1
130
2
QnA에서 Join 필드 표현법
1
90
1
결제서비스 콜백 동시성문제 가능성
1
110
2
굿
1
109
1
도메인/엔티티 분리 상황에서 쓰기 작업 하는 방법
1
137
2
도메인 객체와 엔티티 객체 사용
1
139
2
CouponService 의존성 의문
1
98
2
상품 목록 조회 고도화 질문
1
112
2
표현 계층에서의 접근 지점이 다양해지는것과 이를 해결하기 위한 파사드의 도입에 대해 제미니님의 생각이 궁금합니다.
1
123
2
제품상세 코드 느끼기
1
144
2