FSD - Reference - Layers

본 글은 https://feature-sliced.design/docs/reference/layers를 해석한 글이다.

 

레이어는 Feature-Sliced Design에서 조직 계층 구조의 첫 번째 레벨이다. 레이어의 목적은 책임(how much responsibility it needs)와 의존 모듈하는 모듈( how many other modules in the app it depends on)에 따라 코드를 분리하는 것이다.

Note
이 페이지에서 모듈은 애플리케이션 내부 모듈을 의미한다. - 파일 또는 index 파일이 있는 폴더. npm 패키지와 혼동하지 마세요.

모든 레이어에는 코드에서 모듈이 가질 책임 규모를 결정하는 데 도움이 되는 특별한 의미론적(semantic) 의미가 있다. 레이어의 이름과 의미는 FSD으로 빌드된 모든 프로젝트에서 표준화되어 있다.

총 7개의 레이어가 있으며, 책임과 의존도가 가장 높은 것부터 가장 낮은 것까지 배열되어 있다:

1. App
2. Processes (deprecated)
3. Pages
4. Widgets
5. Features
6. Entities
7. Shared

모든 프로젝트에서 위의 모든 레이어를 사용할 필요는 없으며, 프로젝트에 가치를 더한다고 생각되는 경우에만 레이어를 추가하면 된다.

Import rule on layers(레이어 가져오기 규칙)

레이어는 응집력이 높은 모듈 그룹인 슬라이스(slices)로 구성된다. FSD는 낮은 결합도를 선호하므로 슬라이스 간 종속성은 레이어 가져오기 규칙에 의해 규제된다:

슬라이스 내 모듈은 다른 슬라이스가 바로 아래 레이어에 있는 경우에만 가져올 수 있다.

예를 들어, `~/features/aaa`가 있다면 `aaa`는 슬라이스다. 그리고 `~/features/aaa/api/request.ts`파일은 `~/features/bbb` 내 모듈 코드를 가져오기 할 수 없다. 그러나  `~/entities`, `~/shared`의 코드와  `~/features/aaa` 내 모든 형제 코드는 가져오기할 수 있다.

Layer definitions

Shared

프로젝트 또는 비즈니스의 세부 사항과 분리된 격리된 모듈 / 컴포넌트 / 추상화. 경고: utility dump처럼 취급하지 말기!

이 레이어는 다른 레이어와 달리 슬라이스로 구성되지 않으며, 대신 세그먼트로 직접 구성된다.

 

content 예시:

• UI kit
• API Client
• 브라우저 API로 작업하는 코드

Entities : 엔티티

프로젝트의 본질(essence)을 함께 형성하는 현실 세계의 개념이다. 일반적으로 비즈니스에서 제품을 설명하는 데 사용하는 용어다.

이 레이어의 각 슬라이스에는 static UI Element, data stores 및 CRUD 작업이 포함된다.

 

slice 예시:

SNS 예	Git 프론트 예(github)
- User - Post - Group	- Repository - File - Commit

TIP
Git 프론트엔드의 예에서 repository에 파일이 포함됨을 알 수 있다. 따라서 repository는 다른 엔티티(entitiy)가 중첩되어 있는 상위 엔티티가 된다. 이는 엔터티의 일반적인 상황이며, 레이어에 대한 가져오기 규칙을 위반하지 않고 이러한 상위 레벨 엔터티를 관리하기가 어려울 때가 있다.

다음은 이 문제를 극복하기 위한 몇 가지 제안이다:
- 엔티티의 UI에는 하위 수준 엔티티를 삽입할 위치에 대한 슬롯이 포함되어야 한다.
- 엔티티 인터렉션과 연관된 비즈니스 로직은 features에 배치해야 한다(대부분의 경우).
- 데이터베이스 엔티티의 타입은 Shared 레이어 내 API client 옆으로 추출할 수 있다.

Features : 피처

사용자가 비즈니스 엔티티와 상호 작용하여 가치 있는 결과를 얻기 위해 애플리케이션에서 수행할 수 있는 작업이다. 또한 앱이 사용자를 대신하여 가치를 창출하기 위해 수행하는 작업도 포함된다.

이 계층의 각 슬라이스에는 가치를 창출하는 작업을 가능하게 하는 인터랙티브 UI 요소, 내부 상태 및 API 호출이 포함될 수 있다.

 

슬라이스 예시:

SNS 예	Git 프론트 예(github)	사용자를 대신해 수행하는 작업
- 인증 - Post 생성 - Group 가입	- File 수정 - Comment 남기기 - Branch 병합	- 다크 모드 감지 - 백그라운드 계산 수행 - User-Agent 기반 작업

Widgets : 위젯

엔티티 및 feature와 같은 하위 수준 단위 구성에서 나온 자급자족형(self-sufficient) UI 블록이다.

이 레이어는 엔티티 UI에 남은 슬롯을 다른 엔티티와 features의 인터랙티브 요소로 채울 수 있는 방법을 제공한다. 따라서 일반적으로 비즈니스 로직을 이 레이어에 두지 않고 대신 features에 유지한다. 이 레이어의 각 슬라이스에는 바로 사용할 수 있는 UI 컴포넌트와 제스처, 키보드 상호 작용 등과 같이 비-비즈니스 로직(non-business)이 포함되기도 한다.

그러나 때로는 이 레이어에 비즈니스 로직을 두는 것이 더 편리할 수도 있다. 일반적으로 Widgets이 (대화형 데이터 테이블과 같이) 상호 작용이 매우 풍부하고 그 안의 비즈니스 로직이 다른 곳에서 사용되지 않는 경우에 적용한다.

 

슬라이스 예시:

SNS 예	Git 프론트 예(github)
- Post Card - User profile header(with actions)	- repository 내 파일들의 목록(with actions) - 스레드 내 코멘트 - repository card

TIP
중첩 라우팅 시스템(예: Remix의 라우터)을 사용하는 경우 플랫(flat) 라우팅 시스템에서 Pages 레이어를 사용하는 것과 같은 방식으로 Widgets 레이어를 사용하여 관련 데이터 가져오기, 로딩 상태 및 오류 경계가 포함된 완전한 인터페이스 블록을 만드는 것이 유용할 수 있다. 같은 방식으로 이 레이어에 페이지 레이아웃을 저장할 수 있다.

Pages

(웹 사이트와 같은) 페이지 기반 애플리케이션의 경우 전체 페이지, (모바일 앱과 같은 ) 화면 기반 애플리케이션의 경우 화면/활동(activities)이다.

이 레이어는 위젯과 구성적 특성(compositional nature)이 비슷하지만 규모가 더 크다. 이 레이어의 각 슬라이스에는 라우터에 연결할 준비가 된 UI 컴포넌트가 포함되며, 때로는 데이터 가져오기 로직 및 오류 처리가 포함되어 있다.

 

슬라이스 예제:

SNS 예	Git 프론트 예(github)
- 뉴스 피드 - 게시판 페이지 - 사용자 공개 프로필	- repoistory 페이지 - 사용자 repositoires - repository 내 브랜치들

Processes

주의
이 레이어는 더이상 사용되지 않는다.
현재 버전의 스펙에서는 이 레이어를 피하고 대신 `features` 및 `app`으로 콘텐츠를 옮길 것을 권장한다.

다중 페이지 인터렉션을 위한 탈출 해치(escpate hatches).

이 레이어는 의도적으로 정의되지 않은 상태(undefined)로 남겨져 있다. 대부분의 애플리케이션은 이 레이어를 사용해서는 안 되며 라우터 수준 및 서버 수준 로직을 app 레이어에 유지해야 한다. app 레이어가 유지 관리가 불가능할 정도로 커져서 언로드(unloading)가 필요한 경우에만 이 레이어를 사용하는 것이 좋다.

App

기술적 측면(예: context providers)과 비즈니스 측면(예: analytics) 모두에서 앱 전반에 걸친 모든 종류의 문제를 다룬다.

이 레이어에는 일반적으로 Shared와 같은 슬라이스가 포함되지 않고 세그먼트가 직접 포함된다.

 

컨텐츠 예제:

• Styles
• Routing
• Store and 다른 context providers
• Analytics initialization