fsd 패턴

FSD 패턴

기능 분할 설계(Feature-sliced Design, FSD)는 모듈 간의 느슨한 결합과 높은 응집력을 제공할 수 있으며, 쉽게 확장할 수 있는 아키텍처이다. 이러한 패턴은 세 가지 구분 개념이 있다. 이러한 세 가지 구분 개념이 곧 depth를 의미하기 때문에 이는 곧 디렉토리의 depth는 3으로 제한됨을 의미한다. 그렇다면 이 가장 상위의 디렉토리들을 중심으로 어떻게 애플리케이션이 구성될까? 이전에 가장 최상위의 layer부터 알아보자

Layer

• app
  • 애플리케이션 로직이 초기화되는 곳
  • 프로바이더, 라우터, 전역 스타일, 전역 타입 선언 등
  • 애플리케이션의 진입점 역할
• processes(depricated)
  • 이 레이어는 여러 단계로 이루어진 등록과 같이 여러 페이지에 걸쳐 있는 프로세스를 처리
  • 이 레이어는 더 이상 사용되지 않는 것으로 간주되지만 여전히 가끔씩 마주할 수 있습니다. 선택적 레이어입니다.
• pages
  • 애플리케이션 각각의 페이지
• widgets
  • 페이지에 사용되는 독립적인 UI 컴포넌트
  • entities가 모인 것들
• features
  • 이 레이어는 비즈니스 가치를 전달하는 사용자 시나리오와 기능
  • 각 이벤트들을 담당하는 로직
  • 선택적 레이어
• entities
  • 비즈니스 엔티티
  • 사용자, 리뷰, 댓글 등과 같이 분리할 수 있는 컴포넌트
  • 핵심 도메인 모델과 비즈니스 로직을 담고 있음
• shared
  • 이 레이어에는 특정 비즈니스 로직에 종속되지 않은 재사용 가능한 컴포넌트와 유틸리티
  • 여기에는 UI 키트, axios 설정, 애플리케이션 설정, 비즈니스 로직에 묶이지 않은 헬퍼 등

각각 7개의 디렉토리들은 기능적으로 세분화되어 각자의 역할을 담당하고, 이러한 요소들이 계층적인 구조를 가지기 때문에 한 방향으로만 흐르는 linear flow를 유지한다. 즉, 위의 사진에서 하나의 layer는 자기 자신을 가리키는 layer 아래의 layer들만 참조 가능하다. 이러한 여러 layer들이 계층 구조를 유지하면서 서로 약한 의존 관계를 가진 상태로하나로 점점 합쳐져 하나의 app이 완성되는 구조인데, 이 점이 FSD의 핵심이자 가장 중요한 법칙이다 추상화한다면 위의 사진과 같이 shared(재사용한 컴포넌트들) → entities(독립된 컴포넌트들) → features(각 컴포넌트의 기능을 명시한 script) → widgets(컴포넌트들이 모여 만든 하나의 큰 컴포넌트 단위) → pages(큰 컴포넌트들이 모여 만든 하나의 페이지) → app(entry point) 의 순서로 하나의 큰 애플리케이션을 위해 계층적으로 올라가면서 결국 마지막엔 이 모든 것이 합쳐진 하나의 애플리케이션이 완성되는 구조이다.

Slices

각자 레이어들 안에는 서브 디렉토리가 존재하는데, 이를 slice라고 한다. slice는 주로 도메인 별로 나눈다. 슬라이스는 특정 엔티티에 대해서 코드를 그룹화 하는데, 추상적인 것에 대한 연결이 아닌 명확한 비즈니스 개체에 대한 연결이 존재하고 이를 코드의 가치에 따라 그룹화한다. 이와 같이 필요한 값에 대해서 독립적으로 다룰 수 있는 디렉토리를 생성한다.

Segment

각 슬라이스는 세그먼트로 구성되며 목적에 따라 슬라이스 내의 코드를 나누는데 도움이 될 수 있다.

• api - 필요한 서버 요청 및 데이터 타입, mapper 등
• UI - 슬라이스의 UI 컴포넌트.
• model - 비즈니스 로직, 즉 상태와의 상호 작용. actions 및 selectors가 이에 해당
• lib - 슬라이스 내에서 사용되는 보조 기능(유틸함수들)
• config - 슬라이스에 필요한 구성값이지만 구성 세그먼트는 거의 필요하지 않음.
• consants - 필요한 상수.

이와 같이 계층적인 디렉토리 구조에서 private한 컴포넌트들을 유지하기 위해 중요한 점이 있는데, index.js의 활용이다. 각 layer바로 아래의 디렉토리들에는 index.js를 두고, 이를 하위 폴더들의 것들에서 전부 import해오고, 상위 계층에서 이 index.js를 Import 해와서 사용하는 방식이다. 이런식으로 캡슐화를 이루어낼 수 있다.

왜 좋을까?

• 높은 응집도: 코드는 영향력의 범위(layer), 도메인(slice), 그리고 기술적 목적(segement)에 따라 관리가 되어, 새롭게 접하는 사람들에게 이해하기 쉬운 정형화된 아키텍쳐를 제공한다.
• 로직 재사용 통제: 각 아키텍쳐의 컴포넌트는 목적과 예상 가능한 의존성 (dependency)을 지닌다. 이는 곧 코드에서 지역적으로 사용할 것과 전역적으로 사용할 것을 엄격하게 구분한다는 뜻이기도 하다. 따라서, DRY 원칙과 적응 가능성간의 균형을 잡아준다.
• 변경이나 리팩토링에 안정적임: 특정 layer의 모듈은 같은 layer의 다른 모듈에서 사용 불가능하다. 다른 상위 layer에서도 마찬가지로 사용 불가능하다. 따라서 독립적인 변경이 가능하여 예상치 못한 결과를 방지할 수 있다
• 균일성: 러닝커브가 높기는 하지만 표준화된 구조덕에 적응 후에는 프로젝트가 보다 수월하게 굴러감