🚀 FSD 사용기, 근데 이제 나만의 규칙을 곁들인

FSD

FSD(Feature-Sliced Design), 기능 분할 설계

FSD가 무엇이죠?

• 프론트엔드 애플리케이션의 구조를 잡는 아키텍처 방법론이다
• 코드 구성에 관한 규칙과 관례를 모아둔 것이다

• FSD는 Layers, Slices, Segments 세가지 파트로 나누어진다
• Depth는 3으로 제한한다

Layers

• src 폴더 아래 최상위 디렉토리이자 애플리케이션 분해의 첫 단계이다
• 최대 7개로 제한되어 있으며, 모든 레이어를 사용할 필요는 없지만, 이름은 중요하다

└── src/
    ├── app/
    ├── processes/ (deprecated)
    ├── pages/
    ├── widgets/
    ├── features/
    ├── entities/
    └── shared/

1. app : 애플리케이션 로직이 초기화 되는 entry point이다
   • 프로바이더, 라우터, 전역 스타일, 전역 타입 선언 등이 여기에 정의된다
2. processes : 여러 단계로 이루어진 등록과 같이 여러 페이지에 걸쳐 있는 프로세스를 처리한다
3. pages : 애플리케이션의 페이지가 포함된다 (브라우저 주소 단위의 컴포넌트)
4. widgets : 페이지에 사용되는 독립적인 UI 컴포넌트가 포함된다
5. features : 비즈니스 가치를 전달하는 사용자 시나리오와 기능을 다룬다. 좋아요, 리뷰 작성, 제품 평가 등이 있다
6. entities : 비즈니스 엔티티를 나타낸다. 사용자, 리뷰, 댓글 등이 포함될 수 있다
7. shared : 특정 비즈니스 로직에 종속되지 않은 재사용 가능한 컴포넌트와 유틸리티가 포함되어 있다
   • UI 키트, axios 설정, type 설정, 애플리케이션 설정, 비즈니스 로직에 묶이지 않은 핼퍼 등이 포함된다

• app과 shared는 다른 레이어들과 달리 슬라이스를 가지지 않으며, 직접 세그먼트로 구성된다
• preocesses는 더 이상 사용 되지 않는다
• 한 레이어의 구성 요소는 반드시 아래에 있는 레이어의 구성 요소만 알 수 있고 임포트할 수 있다

Slices

• 레이어의 내부 폴더들이며, 슬라이스는 도메인에 따라 레이어를 나눈다
• 자유롭게 이름을 선택할 수 있고, 원하는 만큼 많이 만들 수 있다
• 같은 레이어 안에서 다른 슬라이스를 참조할 수 없으며, 높은 응딥도와 낮은 결합도를 유지하는 데 도움이 된다

Segments

• 슬라이스 내부 폴더들이며, 세그먼트는 코드의 기능적 목적, 다시말해 코드가 수행하는 역할에 따라 나눈다
• 세그먼트 이름은 표준에 의해 제한되지 않지만, 일반적인 목적을 위한 몇 가지 관례적인 이름이 있다

1. ui : UI와 관련된 모든 것 - 컴포넌트, 날짜 포맷터, 스타일 등
2. api : 백엔드 사용호작용 - request 함수, 데이터 타입, mapper 등
3. model : 데이터 모델 - 스키마, 인터페이스, 스토어, 비즈니스 로직
4. lib : 슬라이스 안에 있는 다른 모듈이 필요로 하는 라이브러리 코드
5. config : 설정 파일과 기능 플래그

FSD를 왜 사용하는 건가요?

프로젝트를 시작할 때, 프로젝트 폴더 구조에 고민을 많이 한다

프로젝트에 대해 모르는 누군가가 읽었을 때, 이해할 수 있는가는 항상 고민거리였다

협업할 때에도 찾기 쉬운 폴더와 파일의 위치는 개발 능률을 올리는 좋은 협업이다

리액트에서 유행하는 패턴이라면 Container-Presenter, Container Component 패턴을 많이 사용한다

데이터와 UI를 기준으로 컴포넌트를 분리하는 패턴들이다

기능을 기준으로 분리하는 FSD는 다음과 같은 장점이 있다

• 균일성
  • 구조가 표준화되어 있어, 프로젝트가 균일해지며, 새로운 구성원이 프로젝트를 이해하기 편하게 해준다
• 변경과 리팩토링에 대한 안정성
  • 한 레이어의 구성 요소는 같은 레이어나 상위 레이어의 다른 구성 요소를 사용할 수 없다. 앱의 사이드 이펙트 없이 격리된 수정을 할 수 있다
• 로직 재사용을 통재
  • 레이어에 따라 코드를 매주 재사용 가능하게 또는 매우 지역적으로 만들 수 있다
• 비즈니스와 사용자 요구에 대한 지향성

단점은 다음과 같다

• 다른 많은 아키텍처 솔루션들에 비해 높은 진입 장벽이 있다
• 인식, 팀 문화 및 개념 준수가 필요하다
• 도전 과제와 문제를 나중이 아닌 즉시 해결해야 한다.

FSD 사용기

일반적인 구조가 아니다보니, 개발을 하는 시간보다 해당 컴포넌트와 기능을 어느 폴더에 위치해야 하는지를 고민하게 된다

리팩토링이라도 하는 날에는 폴더 구조가 날뛰고, 점점 생각했던 이상적인 FSD 패턴과 멀어지는 느낌을 받았다

리팩토링 전에 잘 설계해야 나중에 안 피곤하다는 것은 장점이 될 수도 있을 것 같다

FSD를 사용하면서 궁금하고 고민했던 부분을 정리했다

페이지의 큰 틀인 layout은 어디에 위치해야 하는가?

react-router에서 중첩 라우팅을 하다보니 Layout 컴포넌트가 생기게 되었다. 어디에 두어야 하는 걸까?

순수한 마크업 레이아웃이 필요하다면 shared/ui 에 보관할 수 있다. 상위 계층을 사용해야 한다면 몇 가지 옵션이 있다

• 레이아웃이 필요 없을 수도 있다. 레이아웃이 몇 줄 밖에 안된다면, 추상화하기보다 각 페이지에서 코드를 중복하는 것이 합리적일 수 있다
• 레이아웃이 필요하다면, 별도의 위젯이나 페이지로 만들고 App의 라우터 설정에서 조합할 수 있다. 중첩 라우팅도 다른 옵션이다

feature와 entity의 차이점은 무엇인가?

entity는 앱이 다루는 실제 개념이다 feature는 앱 사용자에게 실제 가치를 제공하는 상호작용, 즉 사람들이 entity로 하고 싶어 하는 것이다