FSD - Reference - Slices and segments
본 글은 https://feature-sliced.design/docs/reference/slices-segments 해석한 글이다.
Slices
슬라이스는 Feature-Sliced Design의 조직 계층 구조에서 두 번째 레벨이다. 슬라이스의 주요 목적은 제품, 비즈니스 또는 애플리케이션에 대한 의미에 따라 코드를 그룹화하는 것이다.
슬라이스의 이름은 애플리케이션의 비즈니스 도메인에 따라 직접 결정되므로 표준화되어 있지 않다. 예는 다음과 같다.
- 사진 갤러리의 슬라이스 : `photo`, `create-album`, `gallery-page` 등
- 소셜 네트워크의 슬라이스 : `post`, `add-user-to-friends`, `news-feed` 등
밀접하게 연관된 슬라이스는 구조적으로 디렉터리에 그룹화할 수 있지만 다른 슬라이스와 동일한 격리 규칙을 적용해야 하며, 해당 디렉터리에 코드 공유가 없어야 한다.
Shared와 App 레이어에는 슬라이스가 포함되어 있지 않다. 그 이유는 Shared에는 비즈니스 로직이 전혀 포함되어 있지 않아야 하므로 제품에 대한 의미가 없고, App에는 전체 애플리케이션과 관련된 코드만 포함되어야 하므로 분할이 필요하지 않기 때문이다.
Public API rule on slices(슬라이스에 대한 public API 규칙)
슬라이스 내에서는 코드를 매우 자유롭게 구성할 수 있으며, 슬라이스에서 좋은 public API를 제공하는 한 문제가 발생하지 않는다. 이는 슬라이스에 대한 public API 규칙으로 강제된다:
모든 슬라이스(및 슬라이스가 없는 레이어의 세그먼트)에는 public API 정의가 포함되어야 한다.
이 슬라이스/세그먼트 외부의 모듈은 슬라이스/세그먼트의 내부 파일 구조가 아닌 public API만 참조할 수 있다.
public API의 근거와 public API를 만드는 모범 사례에 대한 자세한 내용은 public API 참조를 읽어보자.
Segments
세그먼트는 조직 계층 구조의 세 번째이자 마지막 단계로, 기술적 특성에 따라 코드를 그룹화하는 것이 목적이다.
몇 가지 표준화된 세그먼트 이름이 있다:
- `ui` : UI 컴포넌트, 데이터 포매팅 함수
- `model` : 비즈니스 로직과 데이터 스토리지, 이 데이터를 조작하는 함수
- `lib` : 보조 및 인프라 코드
- `api` : 외부 API와의 통신, 백엔드 API 메서드
사용자 지정 세그먼트는 허용되지만 신중하게 만들어야 한다. 사용자 지정 세그먼트가 가장 일반적으로 사용되는 위치는 슬라이스가 적합하지 않은 App 레이어와 Shared 레이어다.
Examples
| Layer | `ui` | `model` | `lib` | `api` |
| Shared | UI 키트 | 보통 사용되지 않음. | 여러 관련 파일의 유틸리티 모듈. 개별 헬퍼를 사용해야 하는 경우 `lodash-es`와 같은 유틸리티 라이브러리를 사용하는 것이 좋다. |
인증( authentication)또는 캐싱(caching)과 같은 추가 기능을 갖춘 기초적인 API 클라이언트 |
| Entities | 대화형 요소용 슬롯이 있는 비즈니스 엔티티의 스켈레톤(더미 데이터?) | 이 엔티티의 인스턴스 데이터 저장소 및 해당 데이터를 조작하기 위한 함수이다. 이 세그먼트는 서버 측 데이터를 저장하는 데 가장 적합하다. TanStack Query 또는 다른 암시적 저장 방법을 사용하는 경우 이 세그먼트를 생략할 수 있다. |
스토리지와 관련이 없는 이 엔티티의 인스턴스를 조작하는 함수 | 백엔드와 쉽게 통신할 수 있도록 Shared의 API 클라이언트를 사용하는 API 메서드 |
| Features | 사용자가 이 기능을 사용할 수 있도록 하는 대화형 요소 | 필요한 경우 비즈니스 로직 및 인프라 데이터 저장소(예: 현재 앱 테마). 실제로 사용자에게 가치를 창출하는 코드이. | `model` 세그먼트의 비즈니스 로직을 간결하게 설명하는 데 도움이 되는 인프라 코드 | 백엔드에서 이 기능을 나타내는 API 메서드. 엔티티에서 API 메서드를 작성할 수 있다. |
| Widgets | 엔티티와 피처를 독립된 UI 블록으로 구성한다. 오류 경계 및 로딩 상태도 포함할 수 있다. |
필요한 경우 인프라 데이터 스토리지. | Non-business 상호 작용(예: 제스처) 및 블록이 페이지에서 작동하는 데 필요한 기타 코드 | 일반적으로 사용되지 않지만 중첩된 라우팅 컨텍스트(예: Remix)에서 데이터 로더를 포함할 수 있다. |
| Pages | 엔티티, 기능 및 위젯을 전체 페이지로 구성한다. 오류 경계 및 로딩 상태도 포함할 수 있다. |
보통 사용되지 않음. | Non-business 상호 작용(예: 제스처) 및 페이지가 완전한 사용자 경험을 제공하는 데 필요한 기타 코드 | SSR 지향 프레임워크용 데이터 로더 |