함께 업무 중인 '프론트 선배님'이 오늘 공부해보라고 알려준 Keyword `FSD`
요즘 디자인 패턴은 fsd가 대세입니다
- 합정 칼퇴러-
🤔 FSD? 그게 뭐지?
프론트엔드 실무를 그래도 2년 정도 찐하게 했다고 생각했는데, 이런 아키텍처 방법론까지는 파고들 생각을 못했다.
프로젝트 구조를 더 안정적으로 만들 수 있도록 이제라도 해보자!
👉🏻 이 글에서 참고한 문서 : https://feature-sliced.design/kr/docs/get-started/overview
1️⃣ FSD 방법론이란?
[Feature-Sliced Design]
- 개요 : 프론트엔드 애플리케이션의 구조를 잡는 아키텍처 방법론
- 방식 : 코드 구성에 관한 규칙, 관례, 도구(린터, 폴더생성기 등)를 모아놓음
- 목적 : 계속 변화하는 비즈니스 요구사항에도, 프로젝트를 더 이해하기 쉽고 안정적으로 만들기 위함
2️⃣ FSD 방법론을 사용하는 이유
1. 프로젝트 구조의 표준화
균일한 프로젝트 구조를 통해, 신규 멤버가 프로젝트에 쉽게 적응할 수 있게 됨
2. 사이드 이펙트 최소화
상위 또는 동일 레이어의 다른 구성요소를 사용할 수 없기 때문에, 불필요한 사이드 이펙트 최소화
3. 로직 재사용성 통제
개발자가 원하는대로, 코드를 전역적 혹은 지역적으로 재사용 가능하게 통제할 수 있음
4. 비즈니스 도메인을 이용한 효율화
비즈니스 도메인을 기준으로 분할되고, 비즈니스 언어를 사용해 작명을 권장
이로 인해, 자신이 개발할 부분과 무관한 부분을 완전히 이해하지 않더라도 충분히 개발 가능
3️⃣ FSD 방법론의 구성
🎃 간단히 예시를 통해 보자면?
1. Layers (레이어)
- 최상위 폴더
2. Slices (슬라이스)
- pages 폴더 내부 폴더들
- 도메인에 따라 나눠짐 (위 예시에서는 페이지별로 폴더화)
3. Segments (세그먼트)
- `app`, `shared`, `pages/article-reader` 내부의 폴더들
- 코드의 기능적 목적 (코드가 수행하는 역할) 에 따라 나눠짐
👻 좀 더 자세히 살펴보자!
1. Layers
- 모든 FSD 프로젝트에서 표준화 되어있음
- 모든 레이어를 사용할 필요는 없으나, 이름은 중요함
- 한 레이어의 구성요소는 자기 아래에 있는 레이어의 구성 요소만 알 수 있고, 임포트 가능
- 위에서 아래로 7층으로 이루어짐
- `App` : [슬라이스 없이, 세그먼트로 구성] 앱 실행 진입점 (라우팅, 전역스타일, 프로바이더 포함)
- `Processes` : Deprecated (더이상 사용X)
- `Pages` : 전체 페이지, 라우팅 페이지
- `Widgets` : 독립적으로 작동하는 대규모 기능, UI 컴포넌트 - 혼자서 완전하게 기능동작할 수 있어야 함
- `Features` : 제품 전반에 걸쳐 재사용되는 기능 구현체
- `Entities` : 프로젝트가 다룰 비즈니스 엔티티 (user, product 등)
- `Shared` : [슬라이스 없이, 세그먼트로 구성] 재사용 가능한 기능, 특히 프로젝트/비즈니스의 특성과 분리된 경우
2. Slices
- 비즈니스 도메인별 코드 분할하여, 논리적으로 관련된 모듈끼리 가까이 유지 -> 코드 베이스를 더 쉽게 탐색 가능!
- 개발자가 원하는 개수, 원하는 이름으로 자유롭게 생성 가능
- 같은 레이어 안에서 다른 슬라이스 참조 불가 => 높은 응집도 & 낮은 결합도 유지
3. Segments
- App, Shared 레이어, 슬라이스 내 구성품 - 목적에 따라 코드를 그룹화
- 표준은 아니라서 꼭 지킬 필요는 없으나, 관례적으로 사용하는 이름
- `ui` : UI 관련 모든 세그먼트 (컴포넌트, 날짜 포맷터, 스타일 등)
- `api` : 백엔드 상호작용 (request, 데이터 타입, mapper 등)
- `model` : 데이터 모델 (스키마, 인터페이스, 스토어, 비즈니스 로직)
- `lib` : 슬라이스 내 다른 모듈이 필요로 하는 라이브러리 코드
- `config` : 설정 파일, 기능 플래그
- App, Shared 에서만 자신만의 세그먼트를 만들게 됨