프론트엔드 개발을 하다보면 폴더 하나에 파일이 너무 많아지거나, 폴더의 깊이(depth)가 너무 깊어지는 상황을 경험할 수 있다.
폴더 구조에 대한 아키텍쳐 중 FSD(Feature Slice Design) 아키텍처가 있다. 이 아키텍처에서는 폴더를 레이어, 슬라이스, 세그먼트의 3가지 개념으로 구성한다.
레이어
레이어에는 고유한 책임 영역이 있다. 가장 중요한 포인트는 레이어간 위계질서가 존재하는 점이다. 위 레이어는 아래 레이어를 import 해올 수 있지만, 아래 레이어에서 위 레이어를 import 할 수 없다.
•
app : 애플리케이션 로직이 초기화 되는 곳. 리액트 프로젝트를 진행한다면 app.tsx , 뷰로 프로젝트를 진행한다면 app.vue 파일이 들어가게 된다. 뿐만 아니라 프로바이더, 라우터 , 전역 스타일, 전역 타입 선언 등을 여기서 정의해주며 애플리케이션의 진입점 역할을 해준다.
•
processes : 로그인이나 회원가입같이 여러단계로 이루어져있는 프로세스를 처리한다. 선택적으로 사용할 수 있는 레이어이다.
•
pages : 애플리케이션의 페이지가 들어간다.
•
widgets : 페이지에 사용되는 독립적인 UI 컴포넌트가 들어간다. 레이아웃(안에 내용은 바뀌지만 틀이 고정적인 것)들이 이 부분에 들어간다.
feature, entites, shared를 설명하기전 예시가 있다.
깃허브 레포지토리를 예시로 들어보면, Fork , Star 같은 부분을 보면 내용물(데이터)는 다른데, 모양은 동일한 것을 볼 수 있다. 내용물(데이터)는 엔티티로 분류하고, 모양이 동일한 버튼은 재사용이 가능함으로 shared, 각 버튼을 눌렀을 때 동작하는 로직은 다름으로 feature에 분류할 수 있다.
또 다른 예시로 예제. Nike Sneaker and Footwear Store 가 있다. 신발 목록들이 나오는 부분에서 각 신발 하나에 대해서는 데이터로 취급하여 Entity로 다루었고, 신발 여러개를 묶은 단위는 widget이 되었다.
•
features : 행동. 사용자 시나리오와 기능을 다룬다.
•
entities : 데이터. 비즈니스 엔티티를 나타낸다.
•
shared : 공유 컴포넌. 특정 비즈니스 로직에 종속되지 않은 재사용 가능한 컴포넌트와 유틸리티가 포함되어 있다.
컴포넌트를 공유할 때 레이어에 index.js 를 만들어 공유하고자 하는 컴포넌트를 export 한다. 외부에서 해당 컴포넌트를 import 할 때 해당 레이어에 존재하는 index.js 에서만 import하여 사용하도록 규칙을 정해야 한다. 이 관점은 객체지향에서 사용하는 캡슐화 개념을 적용한 것이다.
슬라이스
두 번째 depth를 담당하는 슬라이스는 추상적인 것이 아닌 비즈니스 엔티티를 다룬다. 주요 목표는 코드를 값별로 그룹화 하는 것이다. 슬라이스의 이름은 비즈니스 영역에 따라 결정됨으로 표준화 되어있지 않다. 슬라이스 끼리 동일한 격리 규칙을 준수해야하며 이 디렉토리에 있는 코드는 직접적으로 공유되지 않아야 한다.
세그먼트
각 슬라이스는 세그먼트로 구성된다. 세그먼트는 목적에 따라 코드를 나누게 된다.
•
api : 서버 요청
•
UI : 슬라이스의 UI 컴포넌트
•
model : 비즈니스 로직. 상태와 상호작용
•
lib : 슬라이스 내 사용되는 보조기능
•
config : 슬라이스 구성&설정 값
•
consts : 상수
공개 API : index.js
각 슬라이스와 세그먼트는 공개 API가 있으며 이름 규칙은 index.js index.ts 가 된다. 필요한 기능만 외부로 추출하며 불필요한 기능은 캡슐화 한다. 인덱스 파일은 외부로부터 진입점이 된다.
장단점
아키텍처 구성요소를 쉽게 추가, 제거, 수정할 수 있고, 표준화를 할 수 있다. 개발 스택과 독립적으로 적용할 수 있다.(하지만 next.js 를 사용할 때 충돌이 발생 할 수 있다.) 비즈니스 지향적인 방법론이다.
하지만 다른 아키텍처에 비하여 러닝커브가 존재하며 공통되는 규칙을 적용시킬 팀 문화가 있어야 한다.
출처
