FSD (Feature-Sliced Design)

공식문서에 있는 구조도를 따라 그려봤다

 

아침에 개발바닥 오픈카톡방에서 FSD를 보고 프로젝트시 폴더구조 정할 때 도움이 될듯하여 공식문서를 짧게 정리 해봤다.

 

FSD 간략한 소개

 

FSD는 프론트엔드를 위한 구조로,  구조화되어 있으면 매번 바뀌는 비즈니스 요구에 더 잘 대응할 수 있으며 프로젝트에 신입 개발자가 투입되었을 때에도 이해하기 쉽기 때문에 나왔다고 한다.

 

FSD는 아주 작은 싱글 페이지 어플리케이션에는 도움이 되지 않을 수 있으나 Google Cloud Admin dashboard 정도의 큰 앱에는 커스텀된 아키텍처가 필요하고 이 때, FSD에 기반하여 만들 수 있다.
이미 프로젝트가 있다면 점진적으로 채택할 수 있다. (FSD를 점진적으로 도입하는 법은 하단에 있다.)

 

FSD 구성

크게 Layers ,Slices, Segments 로 구성된다.

 

- Layers

 

Layers는 총 7개로 구성되어 있고 수직으로 정렬된다

1. shared : 재사용 가능한 기능, 프로젝트/ 비즈니스의 특정 부분과 떨어져있음(ex. UI kit libs, API) 
2. entities: 비지니스 엔티티들 (User, Product, Order) 
3. features : 유저의 상호작용들(ex) sendComment, AddToCart, UserSearch)
4. widgets: entities 와 features를 의미있는 것으로 합치는 구성 단계
5. pages: entities, features 그리고 widgets를 페이지로 구성하는 단계
6. process(deprecated) : 복잡한 페이지간의 시나리오들
7. app: 어플에서 전체적으로 사용되는 구성들, 스타일들, provider들

 

※ 대부분의 경우 즉 API Client가 저장소도 되는 경우(Graph QL,Tanstack Query, etc)가 아닌 경우에 api와 config는 shared layer에만 위치시키도록 권장된다

 

- Slices 

 

코드를 비즈니스 도메인별로 구분하는 것이다

응집도는 높이고 결합도는 낮추는 데 도움을 준다

 

-Segments

 

각각의 Slices 는 Segment로 이루어진다.

 

FSD를 점진적으로 도입하는 법

1. app 폴더와 shared layer에 해당하는 것들을 서술한다.

2. FSD의 규칙을 위반할지라도 widgets 와 pages 들로 전반적인 기존 ui를 분배한다.

3. features와 entities를 분리하는 것으로 분해의 정확도를 점진적으로 높인다.  pages 와 widgets를 비지니스 로직을 가진 레이어가 아닌 순수하게 구성적인 layer로 바꾼다.

 

- 폴더에 따른 구성

 

app/ 저장소와 글로벌 스타일, 라우터 구성
pages/ 앱의 각각의 페이지에 대한 라우트 컴포넌트들, 로직은 거의 없음
widgets/ (widgets,features, entities는 공식문서에 예시로 깃허브와 트위터의 예시가 있는 데 예시를 보는 것을 추천한다)
features/
entities/ 

 

 

 

공식문서에 있는 튜토리얼을 따라 해보았다

정리 및 느낀 점

 

기존에는 copmonents , api, utils 라는 폴더를 만들어서 했는데 FSD에서는 기능에 따라서도 나누어서 공식문서에 나온 것처럼 각 계층이 한 가지 일만 하도록 하도록 하는 것이  더 잘 느껴졌다. 

응집도를 높이고 결합도를 낮추는 것이 좋은 것이라고 배웠는데 확실히 FSD 를 도입하면 도움이 될 듯하다.