격벽에 대한 내용을 코드로 표현 시 질문이 있습니다!

Question

안녕하세요 유투브를 쭉 챙겨보다 강의를 내셔서 바로 달려온 구독자 중 한명입니다 ! 다름이 아니라 섹션 2의 개념 정리 에서 개념도의 격벽에 대한 내용을 코드로는 어떤식으로 표현되는지를 좀더 확실히 이해하고 싶어 질문드립니다. 현재 상품 과 카테고리 테이블 구조는 N : N 으로 되어있고 ProductCategory 는 이 다대다 관계를 연결하는 매핑 테이블 로 이해했습니다. 그렇다면 상품 과 카테고리 는 서로가 서로를 알지 못하는 격벽으로 나눠져있으며 모든건 이 매핑 테이블 인 ProductCategory 로 이뤄지고 상품과 카테고리의 정보를 가져오기 위해서는 두 개념은 서로를 알지 못하니 ProductFinder 에서 ProductCategoryRepository 를 사용해 Category 를 얻은 후 Product 를 반환한다. 가 제가 이해한 격벽을 구현한 코드가 맞을까요 ? 또 이 격벽을 위한 코드에서 조인을 사용하지 않는 이유가 궁금했습니다. RDBMS과 NoSQL의 차이점 하나가 JOIN으로 알고 있는데 JOIN을 사용하지 않고 개별적으로 접근한다는 점이 조금 새롭게 다가왔거든요. 기존에 다른 수강생 분들의 QA를 종합해서 정리했을 때는 다음과 같이 정리됐습니다. 무적의 한방 쿼리 사용을 지양 (쿼리가 점점더 비대해짐) 조인을 사용하지 않음으로써 다양한 조합(재사용)이 가능 복잡한 쿼리문을 들여다보지 않고 각 쿼리문들을 통해 로직의 흐름을 파악할 수 있다??? 제가 이해한 내용이 맞을까요?? 항상 잘 보고있습니다! 감사합니다!

제미니 · Answer

안녕하세요 질문 감사합니다! 모든건 이 매핑 테이블 인 ProductCategory 로 이뤄지고 이 부분이 격벽을 넘어서 참조하는 부분을 의미한 것이면 맞습니다! 다른 부분은 맞게 이해하신 것 같습니다! 핵심은 Product 가 Category 를 직접적으로 모르고 매핑을 통해서 격벽을 넘어간다라고 이해해주시면 될 것 같습니다! 전반적으로 잘 이해하신 것 같습니다, 당연히 Join은 필요 시 사용하면 됩니다! 다만 로직을 작성하고 테스트를 할때도 모든 것이 큰 쿼리 기반 으로 동작하면 소프트웨어가 점점 쿼리(디비) 기반의 소프트웨어 가 된다고 생각합니다. 저는 올바른 소프트웨어는 코드가 중심이 되고 쿼리는 데이터를 가져오는 전략 중 하나라고만 봐야한다고 생각합니다. 😃 이 관점에서 굳이 join 을 하지 않아도 충분한 경우라면 굳이 할 필요가 없다고 생각합니다 또한 Join 을 걸더라도 (어드민 코드 제외) 개념과 격벽의 기준을 적절히 판단하여 너무 큰 쿼리를 만들지 않는게 핵심 이라고 봅니다! 모쪼록 완강까지 화이팅입니다! 완강 후 수강평도 기대하겠습니다! 추가 질문이 생기시면 편하게 질문주세요!