기능 분할 설계(Feature-Sliced Design) : FSD 아키텍쳐

아키텍쳐에 대해 고민해보기는 처음이었는데, 기존에 사용하던 방식들은 재사용 측면에서 불편한 점들이 있었다.
(기존에 사용하던 방식 : 공통적으로 쓰이는 로직들을 components 디렉터리 안에 위치 시켜 사용)
 

- 이 방식의 단점

1) 어떤 컴포넌트가 특정 도메인이나 페이지 전용인지, 재사용 가능한 범용 컴포넌트인지 구분하기 어려움
2) 프로젝트가 커질수록 불편해짐
-> 공통 컴포넌트를 찾는 데 시간 소요
-> 경로를 변경하거나 재구조화할 때 종속된 파일들의 경로를 모두 업데이트 필요
3) UI 컴포넌트와 비즈니스 로직이 뒤섞일 확률 높음.
4) components 디렉터리가 여러 도메인이나 페이지에 걸쳐 사용되면서, 도메인 간 의존성이 복잡해지고 의도치 않은 종속성이 발생
 
이 단점을 보완할 수 있는 방식이 FSD 아키텍쳐 라고 한다.
FSD 아키텍쳐는 애플리케이션을 기능 단위로 분할하여 관리하는 아키텍처 방법론 이다.
이미 많은 회사에서 사용중인 아키텍쳐이고, 현재 작업중인 프로젝트에서도 활용중인 방식이라 공부해보려 한다 ㅎㅎ
 
사실 이 아키텍쳐가 어렵다고 느껴진 점은 '어디에 위치시킬까'에 대한 고민 때문이다.
전에는 단순하게 components 디렉터리 안에 컴포넌트를 두었고, 공통 로직 같은 경우에도 common/components 안에 두면 되었기에 큰 고민 없었는데, fsd 아키텍쳐의 경우에는 widgets/features/entities/shared 이렇게 네가지의 위치에 대한 고민이 생겼다.
 

FSD 아키텍쳐는 크게 세 가지로 구성되어 있다.
 
레이어(layer) & 슬라이스(slice) & 세그먼트(segment) 인데,
레이어에서는 작성해놓은 내부 순서들도 중요하니 참고!
 

1. 레이어(layer)

좌측이 제일 낮은 레벨, 우측이 가장 높은 레벨

 
1) app
애플리케이션의 진입점 (= 애플리케이션 로직이 초기화되는 곳)
프로바이더, 라우터, 전역 스타일, 전역 타입 선언 등을 정의함.
ex. page, layout..
 
2) pages
애플리케이션의 페이지가 위치하는 레이어
페이지를 기준으로 독립적인 기능들을 모아주는 역할
보통은 페이지에서 얘를 import하고, 이 안에서는 하위 애들을 가져온다.
 
3) widgets
페이지에 사용되는 독립적인 UI 컴포넌트 
하위에 있는 features와 entities 모두 유동적으로 사용 가능한 아이들이라 헷갈렸는데, 그 중 widgets가 가장 큰 단위이다.
ex. header
(header가 widgets이라고 치면, 그 안의 작은 요소들은 그 하위 애들인 features나 entities에 들어간다.)
 
4) features
사용자 시나리오와 관련된 비즈니스 로직을 다룸.
ex. pagination, filterbutton
 
5) entities
최소한의 데이터를 다루는 액션 단위
ex. filtermodule
 
6) shared
모든 레이어에서 사용될 가능성이 있는 가장 작은 단위
특정 비즈니스 로직에 종속되지 않고 재사용 가능한 컴포넌트와 유틸리티, 공통 코드 등이 위치
UI 키트, axios 설정, 애플리케이션 설정, 비즈니스 로직에 묶이지 않은 helper등이 여기 포함된다.
 
+ processes(deprecated) : 더 이상 사용되지 않음
 

2. 슬라이스(slice)

: 위의 6개의 레이어는 slice(ex. userGallery,...)라는 하위 디렉터리가 존재.
슬라이스의 주요 목표는 코드를 값 별로 그룹화 하는 것
 

※ 다른 레이어들과 달리, app과 shared 레이어는 슬라이스를 가지지 않으며, 직접 세그먼트로 구성된다.
(app 레이어는 전체 애플리케이션과 관련된 코드만 가지고, shared 레이어는 비즈니스 로직을 포함하지 않으므로)
 

3. 세그먼트(segment)

: 슬라이스들을 구성하는 요소
 
여기부터는 각 회사나 프로젝트마다 다양한 방식으로 구현할 것 같다.
예시랑 다르게 사용하고 있는 부분이기도 하고, 예시마다 다르게 나와있는 부분이기도 하다.
 
1) ui
2) api
3) model
 
정도로 구성되어 있다.
 

* 특징

• 상위 레이어는 하위 레이어만 참조할 수 있음
  • (features 레이어가 entities 레이어보다 더 위에 있기 때문에, entities 레이어는 features 레이어의 기능을 사용할 수 없음)
  • 선형적인 흐름이 유지되어 의존성을 체계적으로 관리.
• 레이어의 위치가 낮을수록 코드의 더 많은 곳에서 사용될 가능성이 높음
  • shared 레이어의 UI 키트는 features, widgets, 심지어 pages 레이어에서도 사용
• 공개 API 사용
  • 각 슬라이스와 세그먼트에는 공개 API가 존재.
  • 공개 API는 index.js 또는 index.ts 파일
  • 이 파일을 통해 슬라이스 또는 세그먼트에서 필요한 기능만 외부로 추출하고 불필요한 기능은 격리한다.

 

* FSD 도입 후 장점

1) 모듈화 : 기능별로 폴더를 나눠 명확한 경계 설정
2) 재사용성 : UI와 도메인 전용 컴포넌트 분리
3) 유지보수 용이성 : 코드 위치를 쉽게 파악, 의존성 관리 용이
4) 스케일링 효율성 : 기능 단위로 확장이 용이
 
 
 
 
- 참고 자료 https://blog.bizspring.co.kr/%ED%85%8C%ED%81%AC/%ED%9A%A8%EC%9C%A8%EC%A0%81%EC%9D%B8-%ED%94%84%EB%A1%A0%ED%8A%B8%EC%97%94%EB%93%9C-%EC%84%A4%EA%B3%84%EB%A5%BC-%EC%9C%84%ED%95%9C-feature-sliced-designfsd%EC%9D%98-%EC%9D%B4%ED%95%B4/

효율적인 프론트엔드 설계를 위한 Feature-Sliced Design(FSD)의 이해 – BizSpring BLOG