너무 궁금했던 부분인데 이사와 겹쳐서 과제를 거의 못했다 ,, 🥲 그래도 FSD의 개념에 대해 이해할 수 있었고 살짝이지만 적용해볼 수 있어서 좋았다. 꼭 다시 해야지..!
- 프로젝트가 커질수록 디렉토리 구조가 무너진다
- 기존 방식은 규모가 커질수록 관심사의 경계가 무너지고 디렉토리 탐색이 어려워짐
- 컴포넌트, 유틸, API 등이 기능이나 도메인이 아닌 역할 중심으로 분리되어 있어 이해가 어렵고 재사용도 힘듦
- 사실 역할 중심으로 분리하는게 익숙해서 도메인 중심으로 다시 설계하려니 너무 헷갈렸다. (ui만 나눴지만..)
- 관심사 분리가 제대로 되지 않음
- 예를 들어 로그인 기능의 UI, API 호출, 상태 관리, 검증 로직이 여러 디렉토리에 흩어짐
- 어떤 코드가 어디에 위치해야 하는지 명확한 기준이 없어 일관성도 떨어짐
- 시간이 지날수록 점점 심해짐
- 코드의 예측 가능성과 유지보수성이 떨어짐
- 새 팀원이 프로젝트에 참여했을 때, 코드의 위치를 파악하기 힘듦
- Layer + Slice + Segment 구조 제안
- 수직: app > processes > pages > widgets > features > entities > shared 레이어 구조로 계층을 나누고
- 수평: ui / model / api / lib / config 세그먼트로 관심사를 분리
- Slice: 특정 도메인(예: product, cart, auth 등)에 대한 폴더 구조 단위
- 규칙 기반으로 파일을 배치하도록 강제
- 기능별로 관련된 모든 코드를 한 곳에 모음 (ex. entities/product/)
- 팀 내 일관된 컨벤션을 유지하고 협업의 효율성을 높임 (진입장벽이 좀 존재할듯)
- 기능과 관심사의 명확한 분리
- 페이지네이션은 피처인가?, 검색 필터 UI는 위젯인가? 같은 고민을 계속 했다.
- 컴포넌트나 로직이 어떤 슬라이스에 속하는지 판단하는게 어려웠다.
- 특히 UI + 상태 관리 (zustand store)의 위치 선정에서 애매함 느낀 것 같다.
- 상태(store)의 역할과 위치 정하기
- post 관련 zustand store는 어디에 둬야할지 등.. 엔티티와 피쳐 사이에 고민이 되었다.