프론트엔드 아티클 스터디에서 한 분이 제로초님이 추천(?)한 아키텍처가 있다며, FSD를 소개해주었습니다. 다른 맥락이지만 함수형 프로그래밍이라는 책을 읽고 추상화 계층의 분리가 중요하다고 늘 생각했습니다만, 프론트엔드 아키텍처 자체를 추상화 계층을 중심으로 만든다는 게 새로웠습니다. 당장 프로젝트에 적용할 수 있을지는 미지수지만, 좀더 알아보고 마음에 공식 문서 (https://feature-sliced.design/)를 보면서 개념을 정리하려고 합니다.
FSD가 무엇인가요?
프론트엔드 애플리케이션을 구축하기 위한 아키텍처 방법론 중 하나입니다. 변화무쌍한 비즈니스 요구에 대응하여, 프로젝트를 좀더 이해하기 쉽고 또 구조화하기 위해 사용합니다.
누구에게 적합할까요?
- 프론트엔드 방법론입니다. 백엔드에 해당되진 않습니다.
- user-facing application에 해당됩니다. 라이브러리나 UI 키트는 해당되지 않습니다
- 단일 페이지로 이루어진 아주 간단한 앱에서는 별 이득이 없습니다. 그러나 FSD로 새로운 사고를 해보는 데 도움됩니다.
- 굉장히 큰 앱인 경우 해당되지 않습니다.( 커스텀 아키텍처가 필요합니다.) FSD에 기반을 둘 수 있지만요.
+점진적으로 적용 가능합니다. (migration 가이드도 있고요)
FSD의 기본
- 하나의 프로젝트는 레이어로 구성되어있습니다. 각 레이어는 슬라이스들로, 각 슬라이스는 세그먼트로 구성되어 있습니다.
- 하나의 레이어에 있는 많은 모듈들은, 자신 하위의 모듈들만 이용할 수 있습니다.
레이어 리스트 Bottom to Top
- shared : 재사용 가능한 기능, 비즈니스로부터 분리된 UI kits, API 등
- entities: 비즈니스에서 주요한 데이터, 정보( User, Product, Order 등)
- features: 유저 상호작용, 유저에게 비즈니스 가치와 관련있는 actions (SendComment, AddToCart, UsersSearch)
- widgets: 엔티티와 기능을 조합하여 의미있는 블록으로 만든 조합 레이어 (IssueList, UserProfile)
- pages: 엔티티, 기능, 위젯으로 구성한 조합적 레이어
- (processes)
- app : 앱 전반에 대한 세팅, 스타일, Provider
- 각 레이어를 비즈니스 도메인 단위로 나누는 slices가 있습니다. 관심사가 유사한 것들끼리 가까이 모듈로 묶습니다. 슬라이스는 같은 레이어에 있는 다른 슬라이스들을 사용할 수 없습니다. 슬라이스는 응집도는 높게, 모듈 간의 의존성은 낮게 유지합니다.
- 슬라이스에는 세그먼트들이 있습니ㅏㄷ. 세그먼트는 기술적인 목적으로 슬라이스 내 코드를 나ㅜ는 데 사용됩니다. 가장 흔한 세그먼트로는 ui, model(store, actions), api, lib(utils, hooks)가 있습니다.
- api, config는 shared에 두기를 추천합니다. 단 API 클라이언트가 저장소 역할도 수행한다면 제외입니다. (GraphQL, TanStack Query 등)