강의 내용을 따라가던 도중에 의문이 생겨서 질문드립니다.

Question

안녕하세요. 태현님, 좋은 강의 감사합니다. 오늘 BookService 코드를 같이 타이핑하던 도중 의문이 생겼습니다. 뭔가 점점 BookService에서 의존을 주입받는 레포지토리가 점점 늘어나고 있음이 그 원인이었는데요.   보통 커머스 서비스의 앱에서 주문 상세 버튼을 누르면 다음과 같은 정보들이 나오는데요. 가게 정보 메뉴 정보, 주문 자체의 정보(주문 일시, 주문번호) 메뉴와 옵션 선택 정보 쿠폰 적용 주문자의 개인정보(주소 및 연락처) 등등.. 물론 내부적으론 어떻게 해결이 되어있겠지만 벌써 주문 상세를 보여주는 기능을 처리하기 위한 서비스에서 엄~청 많은 레포지토리를 가져와야할 것 같은? 느낌이 듭니다. 이런 경우엔   의존 주입을 받는 객체의 갯수의 상한선을 따로 두고 개발하실까요? 아니면 이런 문제를 해결하는 방법론 같은 것이 이미 있나요? 혹은 제 생각엔 짤막하게 배운 디비 지식으로 주문과 같은 것은 반정규화로 테이블을 합쳐서 그 테이블과 대응되는 하나의 레포지토리로만 가져오나요? 감사합니다.

최태현 · Answer

안녕하세요! wisehero님! 🙂 정말 좋은 질문이십니다. 👍 결론부터 말씀드리면, 상황에 따라 다르지만 크게 repository 개수에 대한 제한을 두지는 않는다 시스템 디자인 관점에서 풀어나가는 경우가 많다. 로 요약드릴 수 있을 것 같습니다. 그 이유는 너무나도 case by case 이기 때문입니다. 예를 들어, 우리가 앱에서 보는 화면에 가게 정보 메뉴 정보, 주문 자체의 정보(주문 일시, 주문번호) 메뉴와 옵션 선택 정보 쿠폰 적용 주문자의 개인정보(주소 및 연락처) 가 있다고 할 때, 이 기능들이 모두 하나의 API에서 반환하고 있다는 보장은 없습니다. 클라이언트가 가게 API / 메뉴 정보 API / 주문 세부 정보 API ... 등등을 각각 호출해서 정보를 조합하고 있을 수도 있고 (클라이언트 <-> 서버 통신이 여러번), 아니면 비슷한 영역끼리 API를 묶어두고 그 API 들을 다시 하나로 묶어 주는 서버가 있을 수도 있습니다. (클라이언트 <-> 서버 <-> 여러 서버 인 셈이죠!) 또한 말씀해주신 " 주문과 같은 것은 반정규화로 테이블을 합쳐서 그 테이블과 대응되는 하나의 레포지토리로만 가져오나요?" 방법을 사용할 수도 있습니다. 👍 (일종의 CQRS 같은 구조를 적용하는거죠) 다만 이 경우, 코드의 의존성을 개선하기 보다는 너무 많은 정보를 여러 테이블에 가져오려 하다보니 성능상의 문제가 발생해, 성능을 개선하기 위해서 적용하는 경우가 다수입니다. 획일화된 해결책을 말씀드리지 못해 아쉽지만 상황에 따라 적절한 방법을 고민하고 적용하는게 개발의 재미인 것 같기도 하네요! 😁 답변이 도움이 되었으면 좋겠습니다. 감사합니다! 🙇