findSections 메서드 위치에 관련하여 질문 드립니다

강의를 듣고 재민 님이 말씀해주신대로 코드를 옮겨 봤는데요.

ProductFinder에 findSections 메서드가 있지 않고 ProductSectionService에서 ProductSectionRepository를 통해 바로 조회하는 것도 꽤 자연스럽고 괜찮다고 느껴졌습니다.

그런데 여기서 궁금한게 있습니다. Product 관련한 건 ProductFinder 라는 별도의 객체가 책임을 갖게 해서 코드를 짜다가, ProductSection에서 갑자기 바로 Repository에 접근해서 조회를 하도록 하면 코드 통일성 측면에서 바람직한가? 하는 의문이 문득 들더라구요.

그렇다고 ProductSectionFinder를 또 만들어서 하자니 너무 과한가? 싶은 생각도 들었습니다. 추가로 ProductSection 조회에 다른 요구사항이 생기거나, 복잡한 구현을 해야 된다면 ProductSectionFinder 같은 걸 만들어도 좋을 것 같은데, 현재 시점에서 만드는 것이 좋은 접근인지 확신이 안 생긴달까요 ㅎ

만약 이런 고민이 들 때는 어떤 것에 우선순위를 두어서 결정하는 것이 좋을 지 재민 님의 의견이 궁금합니다. 좀 더 자연스러운 흐름대로 짜는 것이 나을지, 혹은 코드 통일성 유지를 위해서 바로 Repository에 접근하는 것은 지양 하면 좋을지 등등 말이죠!

이건 회사나 팀마다 정해진 규칙이 있을 가능성이 높지만 공부하는 입장에서 궁금증이 들어 이렇게 질문을 드립니다.

감사합니다😀

아주 흥미로운 고민을 하고 계시군요! 강의를 잘 활용 중이신 것 같습니다 😄

우선 가장 중요한 건 이런 전략은 회사마다 팀마다 정해져있는 상태인 경우가 많습니다!
(최소한 이런 것들 신경쓰지말고그냥 막 하자!라고 하는 회사도 결정한 것이니까요!)

사실 제 우선순위라 하면 가장 중요한 것이 회사/팀의 역량 수준이 들어가버립니다

그렇기 때문에 같이 일하는 동료들의 역량이 조금 아쉽다면, 약간의 경직 된 룰을 만들어서 팀을 유도합니다
ex) ProductSectionService 에서 Repository 직접쓰지 말고 ProductFinder 나 ProductSectionFinder 만듭시다!

물론 이 수준을 영원히 유지하지 않습니다 신입 팀원들이 어느정도 도메인에 익숙해지고, 구현에 익숙해진다면 좀 더 유연한 룰로 변경해나가는 것을 진행하는편입니다.

그래서 단순히 코드를 느끼긴하지만 같이 일하는 동료를 기준으로 판단하는게 1순위가 되는 것 같습니다

일단 다시..! 이번 강의에서 설정한 상황에 몰입하여보면 지금은 ProductSectionService 에서 ProductSectionRepository 를 접근해서 처리하는 것도 괜찮은 선택이라 생각합니다!

그렇다면 만약 베스트 팀이라면 제 경우는 소프트웨어가 성장하는 시점에 맞추어서 성장시키는 것을 선호하기 때문에 굳이 과하게 만드는 방향으론 개발을 하지 않습니다
(다만 제 커리어상으로도 회사에서 이렇게 할 수 있는 팀을 만난 것은 딱 한번 정도 같습니다 ;ㅁ; 현실적으로 어렵습니다......)

그래서 대부분 조금 타이트하게 통제된 정책을 만들고, 회사에서 사람이 바뀌거나 신입이 들어오더라도 적응하기 쉽고 작업하기 쉬우면서 품질을 직관적으로 볼 수 있는 형태를 더 선호합니다!

도움이 되셨길 바라며 완강까지 힘내주시고 수강평도 부탁드립니다!
감사합니다!

인프런 커뮤니티 질문&답변