FSD 에서의 tanstack query 구조 질문드립니다.

충분히 고민할 수 있는 좋은 포인트인 것 같아요..! 정답이 정해져 있다기 보다는 프로젝트 규모, 팀 합의, 도메인 복잡도에 따라 달라질 것 같아요 이미 말씀해주신 해결책 2가지를 조금 정리해봤는데요. 아래 정리한 선택지?타협안?을 고려해봐주셔도 좋을것 같아요 2가지 선택지 도메인 기준 최상위 feature/entity에 쿼리팩토리 위치 html features/ user/ api/ getUser.ts queries/ useUserQuery.ts (팩토리로 구현) model.ts entities/ post/ api/ queries/ • 장점: 도메인 경계와 쿼리 팩토리 책임이 동일(features, entities layer 안에 있기 때문에) • 단점: 서로 다른 feature에서 하나의 쿼리를 써야하는 상황에서 중복 발생 -> 재정의 필요 shared/data-access(혹은 shared/infra) 폴더 도입 tsx shared/ data-access/ user/ queries.ts (팩토리) api.ts post/ queries.ts • 장점: 여러 도메인/feature에서 동일 쿼리팩토리를 import하여 사용 가능 • 단점: shared/data-access가 커지면 실질적 도메인 로직이 shared에 몰리게? 됨 이 경우, shared/data-access는 엄밀히 말해 infra-layer 또는 API Layer로 생각할 수도 있을것 같아요. 결론 2가지 선택지 중에 고를 때 고려할 점 몇가지를 안내드리면서 저라면 shared 를 선택할 것 같다는 의견 남겨요 ㅎㅎ • FSD를 너무 정교하게 지키려다 보면 실제 코드의 응집도/가독성이 오히려 더 떨어질 수 있더라구요. • 쿼리팩토리(특히 react-query의 useXxxQuery)는 실질적으로 데이터 접근 계층(data-access layer)으로 간주하는게 합리적일 것 같아요. • 프로젝트 규모가 크고, 여러 feature/entity에서 동일 데이터를 여러 번 읽는 경우라면 더더욱 → 아예 shared/data-access로 분리하는 것이 유지보수에 유리할 것 같습니다. • 반대로, 각 도메인 내부에서만 쓰는 쿼리라면 feature/entity 하위에 보관해도 괜찮을것 같아요. • 나아가서 두 방식이 혼용되는 것도 고려할 수 있을것 같아요 • 단, 어느 쪽이든 "무엇이 어디까지 책임지는가" 책임 범위를 명확히 문서화하고, 팀 내 컨벤션을 잡는 것이 중요할 것 같습니다

프로젝트를 하다보면 A라는 도메인에서도 B, C 도메인의 api에 접근해야 하는 경우가 많아서 저는 shared에 둘 것 같아요. 그리고 이것이 책임을 몰아준다는 느낌보다는 오히려 책임이 잘 부여되었다 라고 생각이 들어요!