- 개요
- 정의: 대규모 프론트엔드 애플리케이션의 구조를 잡기 위한 아키텍처 방법론
- 목적: 애플리케이션을 기능 단위로 분할하여 프로젝트를 더 이해하기 쉽고 구조적으로 만들어, 프로젝트의 규모가 커져도 유지보수에 유리하도록 함
- 구조
- 레이어의 이름은 제한적, 슬라이스와 세그먼트의 이름은 자유
- 슬라이스는 보통 비즈니스 도메인별로 분리하며 세그먼트는 보통 관례적인 이름 사용
- Layers
- Slices
- Segments
- Slices
- Layer
- 프로젝트를 최상위부터 가장 기본적인 요소까지 단계적으로 나눈 폴더로 첫 번째 수준의 계층 구조
- app, processes, pages, widgets, features, entities, shared의 7개로 구성
- 현재는 processes 제외 6개의 레이어만 사용됨
- app: 애플리케이션 전체의 전역 설정만 담당하며 슬라이스가 없고 세그먼트만 가짐
- 라우팅, 전역 스타일, 테마 설정 등
- progesses: 페이지 간 복잡한 시나리오나 워크플로 관리
- 현재는 복잡성, 중복성의 문제로 사용하지 않음
- pages: 앱 내 개별 페이지 정의, 사용자 인터페이스와 관련된 로직 처리
- widgets: 페이지 내 독립적으로 작동하는 큰 기능 단위. 검색 바, 대시보드, 사이드바 메뉴 등이 해당함
- Features: 재사용 가능한 비즈니스 기능을 위함, 독립적으로 동작할 수 있는 하나의 특정 동작을 정의함
- 다양한 페이지와 위젯에서 사용할 수 있도록 기능을 추상화하는 레이어
- Entities: 프로젝트에서 다루는 비즈니스의 핵심 데이터를 나타내는 레이어
- 주로 데이터 모델과 해당 데이터에 대한 로직이 포함됨
- Shared: 프로젝트 전반에서 재사용할 수 있는 유틸리티, 기본적인 컴포넌트, 스타일 등의 전반적인 리소스를 포함하는 레이어, 슬라이스가 없고 세그먼트만 가짐
- Button 컴포넌트 등
- 단방향 의존성: 상위 레이어는 하위 레이어만 참조하며, 레이어 간 수직적 위계와 독립성을 엄격히 보장함
- 하위 레이어 참조 제한으로 규칙 확산을 방지하며 계층 간 결합도를 낮추고 모듈의 응집도를 강화함
- Slice
- 애플리케이션을 비즈니스 도메인별로 코드를 분리하는 두 번째 수준의 계층 구조
- 특정 비즈니스 엔티티에 대한 코드를 묶음
- 사진 갤러리 프로젝트는 사진, 앨범, 갤러리
- 소셜 네트워크 프로젝트는 게시물, 사용자, 뉴스피드
- 같은 레이어 안에서 다른 슬라이스를 참조할 수 없고 필요 시 하위 레이어의 공통 요소들만 참조 가능
- 높은 응집도와 낮은 결합도를 갖기 위함
- 슬라이스는 독립적으로 관리될 수 있으며 도메인에 집중
- 슬라이스 간 종속성 최소화
- Segment
- 기능별로 분리된 세그먼트들이 존재하여 각각의 세부 기능을 담당하는 세 번째 수준의 계층 구조
- 이름을 제한하지 않지만, 관례적인 이름 사용, 아래는 User 슬라이스의 세그먼트 예시
- model
- 상태 관리 및 비즈니스 로직을 포함하여, 사용자 정보나 팔로우 상태와 같은 데이터 저장 및 관리
- ui
- 사용자 인터페이스를 구성하는 컴포넌트를 포함하여, 사용자 정보 조회 화면 등의 UI 요소 제공
- api
- 서버와의 데이터 교환을 위한 API 요청 코드를 포함하여 백엔드와 데이터를 주고받는 역할
- lib
- 유틸리티 함수나 헬퍼 함수와 같이 해당 도메인에서 반복적으로 사용되는 기능 제공
- 공개 API 정의 규칙
- 각 모듈이 외부에서 사용할 수 있는 것을 명확하게 선언하는 역할
- index.js 파일을 만들어 외부에 공개할 파일이나 함수를 다시 내보냄
- 외부에서는 index.js만 사용하므로 슬라이스 안의 코드를 직접 알 필요가 없음
- 슬라이스가 없다면 세그먼트별 공개 API 정의, 슬라이스가 있다면 해당 슬라이스의 공개 API 정의
참고
https://feature-sliced.design/docs/get-started/overview
https://velog.io/@clydehan/FSDFeature-Sliced-Design-%EC%99%84%EB%B2%BD-%EA%B0%80%EC%9D%B4%EB%93%9C
