FSD architecture
📌 FSD 아키텍쳐란?
Feature-Sliced Design(FSD)은 대규모 프론트엔드 애플리케이션의 구조를 잡기 위한 아키텍처 방법론이며, 직역하면 '기능 분할 설계'이다. 간단히 말해, 코드를 조직적으로 구성하기 위한 규칙과 관례의 모음이다. 이 방법론의 주요 목적은 애플리케이션을 기능 단위로 분할하여 프로젝트를 더 이해하기 쉽고 구조적으로 만들어, 프로젝트의 규모가 커져도 유지보수에 유리하도록 하는 데 있다.
FSD의 계층 구조는 크게 레이어, 슬라이스, 세그먼트로 나뉘며, 이는 프로젝트의 폴더 구조 트리로 볼 수 있다. 폴더 구조의 최상위에는 레이어가 위치하고, 각 레이어는 슬라이스를 포함한다. (단, app과 shared는 슬라이스를 가지지 않고 직접 세그먼트를 포함하며, 이에 대한 내용은 아래 각 계층 설명에서 다룬다.) 또한, 각 슬라이스는 세그먼트를 포함하게 된다.
레이어의 이름은 제한적이지만, 슬라이스와 세그먼트의 이름은 자유롭게 선택할 수 있으며, 필요한 만큼 만들 수 있다. (슬라이스는 보통 비즈니스 도메인 별로 분류하며, 세그먼트는 일반적으로 몇 가지 관례적인 이름을 사용한다. 이에 대해서도 아래 각 계층 설명에서 다룬다.)
📌 레이어 (Layers)
레이어는 프로젝트를 최상위부터 가장 기본적인 요소까지 단계적으로 나누어 구성한 폴더 구조의 기본 계층이다. FSD의 레이어는 app, processes, pages, widgets, features, entities, shared 총 7개로 구성되며, 현재는 processes 레이어가 사용되지 않아 실제로는 6개의 레이어만 사용된다.
각 레이어는 고유한 목적을 가지고 있으며, 반드시 모든 레이어를 사용할 필요는 없다. 그러나 사용하게 된다면 일관된 구조와 명명 규칙을 지켜 프로젝트를 더 이해하기 쉽고 유지보수하기 용이하게 해야 한다. 따라서 사용 시에는 각 레이어의 이름을 정확히 지켜야 한다.
💡 App 레이어
프로젝트의 진입점이자 가장 상위의 전역 설정을 포함하는 레이어다. 주로 앱의 시작점이나 주요 설정을 관리한다. 라우팅, 글로벌 스타일, 최상위 프로바이더 등을 포함한다. 앱이 시작할 때 특정 테마를 적용하거나 글로벌 상태 관리를 초기화할 필요가 있는 경우 App 레이어에서 이를 설정할 수 있다.
쉽게 말해 App 레이어는 애플리케이션의 전반적인 구성을 관리하는 곳으로, 프로젝트의 루트 구성과 초기 설정이 이루어지는 곳이다. 모든 애플리케이션의 구성 요소가 이 레이어에서 시작된다.
예를 들어 ThemeProvider를 사용해 전체 앱에 다크모드 또는 라이트모드를 적용하는 설정을 포함할 수 있다.
App 레이어는 애플리케이션 전체의 전역 설정만 담당하는 레이어라서 슬라이스가 없고 세그먼트만 가지는데, 애플리케이션의 전역 설정들이 한 곳에서 모여 있어야 관리가 편리하기 때문이다. 예를 들어, 라우팅, 전역 스타일, 테마 설정은 애플리케이션 전반에 걸쳐서 한 번만 설정해두면 되며, 여러 위치에 분산될 필요가 없다.
이렇게 세그먼트로 바로 모아두면 프로젝트 시작 시 설정해야 하는 모든 전역 설정들을 쉽게 찾아 수정할 수 있다. 반면, 슬라이스는 기능별로 더 세분화해 나누는 구조라 App 레이어의 간단한 전역 설정에 사용될 필요가 없다.
💡 Processes 레이어 (현재는 사용되지 않음)
Processes 레이어는 페이지 간의 복잡한 시나리오나 워크플로를 관리하기 위해 사용되었다. 예를 들어, 사용자 가입이나 결제 처리처럼 여러 페이지에 걸쳐 진행되는 복잡한 절차를 포함했지만, 복잡성 증가와 다른 레이어와의 중복성 때문에 현재는 사용이 권장되지 않는다. 대신 이와 같은 흐름은 Pages 또는 Widgets 레이어로 분산하여 관리할 수 있다.
💡 Pages 레이어
Pages 레이어는 앱 내 개별 페이지를 정의하는 레이어이다. 특정 URL에 매핑되는 전체 페이지를 구성하며, 주로 라우팅과 관련된 파일이나 페이지에 해당하는 최상위 컴포넌트를 포함한다. 예를 들어 /home, /profile, /settings와 같은 각각의 페이지를 구성하는 컴포넌트들이 이에 해당한다.
Pages 레이어는 사용자에게 바로 노출되는 UI 요소이므로 복잡한 비즈니스 로직보다는 사용자 인터페이스와 관련된 로직을 처리한다. 이 레이어는 사용자에게 보여지는 완전한 페이지를 구성하며, UserPage와 같은 경우 사용자 관련 정보와 관련된 여러 widgets와 features가 함께 모여 하나의 페이지를 이루게 된다. 예를 들어 UserPage는 사용자 프로필 정보, 설정 관리, 활동 내역 등의 다양한 위젯을 포함해 구성될 수 있다.
💡 Widgets 레이어
Widgets 레이어는 페이지 내에서 독립적으로 작동하는 큰 기능 단위를 포함하는 레이어이다. 이 레이어는 독립적으로 기능하는 큰 규모의 UI 컴포넌트나 기능 블록을 구성하여 다양한 페이지에서 재사용할 수 있다. 예를 들어 검색 바, 대시보드, 사이드바 메뉴 등이 이에 해당한다.
Widgets는 독립적으로 기능할 수 있으며 다양한 페이지에서 재사용 가능하다. 쉽게 말해, 하나의 위젯은 여러 개의 features와 entities를 포함하여 더 높은 수준의 UI를 구성한다. 예를 들어 UserProfile 위젯은 사용자의 정보(사진, 이름, 팔로워 수 등)를 표시하는 컴포넌트로 구성되며, 이 위젯에는 FollowUser와 같은 features 레이어의 기능이 포함되어 사용자가 다른 사용자를 팔로우할 수 있는 기능을 제공한다. 이러한 위젯은 UserPage, HomePage 등 여러 페이지에서 재사용할 수 있다.
💡 Features 레이어
Features 레이어는 재사용 가능한 비즈니스 기능을 위한 레이어로, 독립적으로 동작할 수 있는 하나의 특정 동작을 정의한다. 예를 들어 사용자 팔로우 기능 (FollowUser)은 features 레이어에 위치해 재사용 가능하고 독립적인 비즈니스 기능으로 동작할 수 있다. features는 다양한 페이지와 위젯에서 사용할 수 있도록 기능을 추상화하는 레이어이다.
일부 슬라이스의 model 세그먼트에 비즈니스 로직이 포함되어 있더라도, features 레이어는 여전히 필요하다. 그 이유는 features 레이어가 여러 페이지와 위젯에서 재사용 가능한 독립적 비즈니스 로직을 제공하기 때문이다. 이 레이어가 없으면 동일한 비즈니스 기능을 구현할 때마다 중복 코드가 발생할 가능성이 높아지고, 특정 기능을 유지보수하거나 업데이트할 때 여러 페이지와 위젯에서 동일한 수정이 필요해 비효율적이다.
따라서 특정 레이어의 model 세그먼트에 해당 레이어 전용 로직을 포함할 수는 있지만, 재사용성과 독립성을 위해 보편적인 비즈니스 로직은 features 레이어에 두는 것이 좋다. 이렇게 하면 여러 페이지에서 동일한 features 기능을 가져다 사용할 수 있어 확장성과 유지보수성이 향상된다.
💡 Entities 레이어
Entities 레이어는 프로젝트에서 다루는 비즈니스의 핵심 데이터를 나타내는 레이어이다. 이 레이어에는 주로 데이터 모델과 해당 데이터에 대한 로직이 포함된다. 예를 들어 User 엔터티는 사용자 관련 정보를 관리하며, 이름, 이메일, 프로필 사진 등 사용자의 주요 정보를 다룬다. Entities 레이어는 다양한 페이지와 위젯에서 사용되는 비즈니스 핵심 데이터와 관련 로직을 제공한다.
💡 Shared 레이어
Shared 레이어는 프로젝트 전반에서 재사용할 수 있는 유틸리티, 기본적인 컴포넌트, 스타일 등의 전반적인 리소스를 포함하는 레이어이다. 이 레이어의 요소들은 특정 기능이나 비즈니스에 국한되지 않고 전반적으로 사용된다.
예를 들어, Button 컴포넌트는 shared 레이어에서 제공된다. 이 컴포넌트는 스타일과 인터랙션을 정의해 여러 기능과 페이지에서 재사용할 수 있다. 다양한 스타일을 지원하는 Button 컴포넌트는 FollowUser 기능이나 UserPage와 같은 여러 페이지와 위젯에서 쉽게 활용할 수 있다.
shared 레이어도 app 레이어와 마찬가지로 슬라이스가 없는데, 이유는 이 레이어가 전역적으로 재사용 가능한 요소들만 모아두기 위한 공간이기 때문이다. shared는 프로젝트 전반에서 공통으로 사용할 수 있는 유틸리티, 기본 컴포넌트, 스타일 등을 포함하며, 특정 기능이나 비즈니스 로직과는 무관하다.
슬라이스는 보통 특정 기능이나 비즈니스 도메인에 맞춰 세분화할 때 사용되는데, shared 레이어는 모든 기능에서 공통으로 사용할 수 있는 요소들을 제공하기 때문에 따로 나누지 않고 하나의 모음으로 관리하는 것이 더 효율적이다.
이로 인해 shared의 요소들은 프로젝트 어느 부분에서도 자유롭게 사용할 수 있으며, 코드의 중복을 줄이고 유지보수성을 높일 수 있다.
💡 레이어 참조 규칙
FSD의 중요한 규칙 중 하나는 단방향 의존성이다. 이는 한 레이어의 구성 요소가 반드시 자신보다 하위 레이어의 구성 요소만 참조하거나 임포트할 수 있다는 것을 의미한다. 이러한 규칙을 통해 코드의 결합도를 낮추고 유지보수를 쉽게 할 수 있다. 예를 들어, Features 레이어는 Shared나 Entities 레이어의 구성 요소를 참조할 수 있지만, Widgets 레이어의 구성 요소는 참조할 수 없다.
이 규칙을 통해 코드의 구조가 명확해지고, 계층 간의 결합도가 낮아지며, 특정 레이어에서 발생한 변경이 다른 레이어로 확산되지 않도록 방지한다.
예를 들어, Shared 레이어의 버튼 컴포넌트를 수정하면 이 컴포넌트를 사용하고 있는 Entities, Features, Widgets 등의 상위 레이어에서 그 변화가 반영된다. 하지만 반대로 상위 레이어에서 발생한 변화가 하위 레이어에 영향을 미치지 않기 때문에, Features나 Widgets 레이어에 추가된 기능이 Shared 레이어의 변경을 일으키지 않는다.
이 규칙은 코드의 결합도를 낮춰 유지보수성을 높인다. 변경 사항이 상위에서 하위로 내려가도록 강제하면서, 특정 레이어의 변경이 해당 레이어와 직간접적으로 연관된 다른 레이어에 확산되는 것을 최소화한다. 이를 통해 특정 기능이나 모듈을 변경해도, 그 영향이 직접 참조 관계에 있는 레이어에만 제한되므로, 불필요한 오류나 연쇄적인 수정 작업을 줄일 수 있다.
💡 FSD 레이어 계층 흐름
FSD의 복잡한 계층 구조를 더 쉽게 이해할 수 있도록 전체적인 흐름을 정리하면 다음과 같다.
Shared레이어:Button과 같은 기본 컴포넌트를 제공하여, 프로젝트 전반에서 다양한 버튼 스타일을 일관되게 사용할 수 있도록 한다.Entities레이어:User엔터티를 정의하여 사용자 데이터를 관리하고, 이를 다양한 컴포넌트에서 활용할 수 있게 한다.Features레이어:FollowUser기능을 정의해, 사용자가 다른 사용자를 팔로우할 수 있는 구체적인 동작을 제공하며,User엔터티와Shared레이어의Button컴포넌트를 함께 활용한다.Widgets레이어:UserProfile위젯에서FollowUser기능을 포함해 사용자 프로필 정보를 표시하며 팔로우 버튼을 제공한다.Pages레이어:UserPage에서UserProfile위젯을 포함하여 하나의 완전한 사용자 페이지를 구성한다.App레이어: 전체 앱의 라우팅과 전역 설정을 관리하고,UserPage가/user경로에서 노출되도록 설정한다.
이렇게 단계별로 구조를 보면 FSD의 계층 구조가 체계적이고 이해하기 쉬우며, 프로젝트를 더 체계적으로 관리할 수 있음을 느낄 수 있다.
📌 슬라이스 (Slices)
⚠️ 주의:
App과Shared는 다른 레이어와 다르게 슬라이스 없이, 직접 세그먼트만 포함한다.
각 레이어는 슬라이스라는 하위 디렉토리를 가지는데,(app, shared 제외) 슬라이스는 FSD에서 애플리케이션을 비즈니스 도메인별로 코드를 분리하는 두 번째 수준의 계층 구조이다. 여기서 중요한 점은, 슬라이스는 일반적인 기능이 아닌 특정 비즈니스 엔티티(예: 사용자, 게시물 등)에 대한 코드를 묶는다는 것이다. 슬라이스의 주된 목적은 각 비즈니스 도메인별로 관련된 코드를 한 곳에 모아, 유지보수와 관리가 용이하도록 만드는 것이다.
예를 들어, 사진 갤러리를 만드는 프로젝트라면 사진, 앨범, 갤러리처럼 각각의 기능을 다루는 슬라이스가 있을 수 있다. 소셜 네트워크 프로젝트라면 게시물, 사용자, 뉴스피드와 같은 슬라이스를 만들게 된다. 즉, 프로젝트마다 필요한 슬라이스의 이름과 내용은 다를 수 있으며, 각각의 비즈니스 도메인에 맞춰 자유롭게 정의하면 된다.
💡 슬라이스의 독립성 유지
슬라이스는 같은 레이어 안에서 다른 슬라이스를 참조할 수 없다. 예를 들어, User 슬라이스는 같은 레이어의 Product 슬라이스를 참조할 수 없으며, 오직 필요한 경우에 한해 하위 레이어의 공통 요소들만 참조할 수 있다. 이러한 규칙이 중요한 이유는 다음과 같다.
- 높은 응집도: 비즈니스 도메인별로 관련된 코드가 하나의 슬라이스에 모두 포함되므로, 각 슬라이스는 독립적으로 관리될 수 있으며 도메인에 집중할 수 있다.
User슬라이스는 사용자와 관련된 코드만 가지고 있으므로, 사용자 기능을 개발하거나 수정할 때 다른 도메인에 영향을 주지 않는다. - 낮은 결합도: 다른 슬라이스와의 참조가 불가능하므로, 슬라이스 간의 종속성이 최소화된다. 이로 인해 슬라이스 간 결합이 낮아져 특정 슬라이스에 변경이 생겨도 다른 슬라이스에는 영향을 주지 않으며, 전체 시스템의 안정성이 높아진다.
때로는 서로 관련 있는 슬라이스끼리 가까이 배치하여 그룹화할 수 있지만, 중요한 규칙은 서로의 코드에 직접 접근해서는 안 된다는 것이다. 각 슬라이스는 고유한 비즈니스 로직과 기능을 담당하며, 다른 슬라이스와는 독립적으로 유지된다. 이를 통해, 각 기능을 독립적으로 개발, 유지보수할 수 있어 코드의 안정성과 확장성이 높아진다.
예를 들어, 사용자(User)라는 비즈니스 도메인에 관한 모든 코드는 User라는 슬라이스에 속하게 된다. 이 슬라이스에는 사용자 정보 조회, 프로필 수정, 팔로우 기능 등이 포함될 수 있으며, 이렇게 관련된 기능들을 한 슬라이스에 모아 두면 코드의 응집도가 높아지고 유지보수가 쉬워진다.
📌 세그먼트 (Segments)
슬라이스 안에는 기능별로 분리된 세그먼트들이 존재하여 각각의 세부 기능을 담당한다. 세그먼트는 세 번째 수준의 계층 구조이다. 세그먼트 이름은 표준에 의해 제한되지 않지만, 가장 일반적인 목적을 위한 몇 가지 관례적인 이름이 있다. 예를 들어 User 슬라이스에는 다음과 같은 세그먼트가 있을 수 있다.
model: 상태 관리 및 비즈니스 로직을 포함하여, 사용자 정보나 팔로우 상태와 같은 데이터를 저장하고 관리한다.ui: 사용자 인터페이스를 구성하는 컴포넌트들을 포함하여, 사용자 정보 조회 화면, 프로필 수정 화면 등의 UI 요소를 제공한다.api: 서버와의 데이터 교환을 위한 API 요청 코드를 포함하여, 백엔드와 데이터를 주고받는 역할을 한다.lib: 유틸리티 함수나 헬퍼 함수와 같이 해당 도메인에서 반복적으로 사용되는 기능들을 제공한다.
이러한 구조적 분리 덕분에 특정 기능에 변화가 생기더라도 관련 세그먼트만 수정하면 되며, 전체 슬라이스에 걸쳐 중복된 코드를 줄일 수 있다.
💡 일반적인 코드 재사용
FSD에서는 보통 기능별로 코드를 분리하지만, 프로젝트 전반에서 여러 곳에서 공통으로 쓰이는 코드가 필요할 때가 있다. 예를 들어, 모든 페이지에서 같은 스타일을 사용하는 버튼이나, 서버와 데이터를 주고받을 때 필요한 기본 API 요청 같은 것들이다. 이런 공통 코드는 Shared 레이어에 모아서 관리한다.
Shared 레이어는 다른 레이어와 다르게 슬라이스가 없고, 세그먼트만 포함한다. 여기에는 프로젝트 전반에서 공통으로 쓰이는 코드가 모이며, 필요한 순간에 추가하는 방식으로 구성된다. 개발을 하다가 "이건 다른 곳에서도 쓸 수 있겠는데?" 싶은 코드가 생기면 그때 Shared에 넣으면 된다.
예를 들어, Shared 레이어에는 다음과 같은 폴더가 있을 수 있다.
- 📂 ui/ — 버튼이나 모달처럼 디자인이 중요한 기본 UI 요소들
- 📂 api/ — 서버와 통신할 때 사용하는 기본 API 함수들
- 📂 config/ — 환경 설정을 관리하는 파일들
- 📂 i18n/ — 다국어 지원 설정을 모은 파일들
- 📂 router/ — 앱의 라우팅 관련 설정 파일들
Shared 레이어의 핵심은, "이 코드가 어디서 쓰일지"보다 "왜 필요한지"에 따라 세그먼트를 구분하는 것이다. 예를 들어, components 같은 이름보다는 ui로 폴더를 나누는 게 목적을 더 명확히 보여준다.
이렇게 하면 프로젝트가 커져도 필요한 공통 코드를 쉽게 찾고, 중복 없이 관리할 수 있어 유지보수하기가 편리해진다.
💡 FSD 슬라이스, 세그먼트 계층 흐름
예를 들어, FollowUser라는 기능을 가진 User 슬라이스를 생각해보자.
- User 슬라이스는
model세그먼트에서isFollowing과 같은 상태를 관리하고,api세그먼트에서 팔로우/언팔로우 API를 호출한다. - 사용자가
FollowUser기능을 클릭하면,ui세그먼트의 버튼 컴포넌트를 통해model세그먼트에서 관리 중인 상태가 변경되고, 팔로우 여부가 즉시 UI에 반영된다.
이렇게 비즈니스 로직과 UI, API 호출을 하나의 슬라이스에서 관리함으로써, 개발자는 전체적인 구조를 쉽게 이해하고 기능을 빠르게 파악할 수 있다. 특정 슬라이스의 기능을 이해하고 수정할 때 해당 슬라이스 안에서 필요한 모든 요소들을 찾을 수 있어, 코드 탐색이 용이하다.
이러한 슬라이스 구조는 규모가 커지더라도 코드 베이스를 쉽게 탐색하고 유지보수할 수 있도록 설계되었으며, 특히 기능의 독립성을 유지하면서도 비즈니스 로직을 분리해 높은 응집도와 낮은 결합도를 보장하게 된다.
📌 엄격한 공개 API 정의 규칙
Feature-Sliced Design(FSD)에서 공개 API는 각 모듈(슬라이스나 세그먼트)이 외부에서 사용할 수 있는 것들을 명확하게 선언하는 역할을 한다. 쉽게 말해, "이 모듈 안에서 외부에 보여주고 싶은 것만 공개하겠다"는 약속이다. 이 구조를 통해 특정 기능이나 컴포넌트의 내부 코드를 외부에서 수정할 필요 없이, 마음 편히 리팩토링(코드를 더 효율적으로 재작성)할 수 있다.
예를 들어, 슬라이스 안에 여러 파일들이 있다고 해보자. 이때 index.js 파일을 만들어서 외부에 공개할 파일이나 함수를 다시 내보내면 된다. 이렇게 하면 외부에서는 index.js 파일만 사용하므로 슬라이스 안의 구조를 직접 알 필요가 없다.
💡 Shared 레이어의 공개 API 구성
Shared 레이어는 슬라이스 없이 여러 세그먼트(UI, API 등)만 가지고 있다. 이런 경우, 각 세그먼트 안에 index.js 파일을 두어 세그먼트별 공개 API를 정의하는 것이 일반적으로 더 편리하다. 이를 통해 Shared 레이어에서 가져오는 파일들이 각각의 세그먼트 목적에 맞게 나뉘어 더 직관적으로 사용된다.
💡 다른 레이어의 공개 API 구성
반면, 슬라이스가 있는 다른 레이어들에서는 보통 슬라이스당 하나의 index.js 파일을 두고, 해당 슬라이스의 공개 API를 정의한다. 예를 들어 pages 레이어에서는 페이지별로 하나의 index.js 파일을 만들어 그 페이지에서 필요한 모든 파일을 한 번에 공개할 수 있도록 한다.
💡 예시
다음과 같은 구조로 FSD의 공개 API를 설정할 수 있다.
📂 pages/
📂 feed/
📄 index.js // 'feed' 페이지의 공개 API
📂 sign-in/
📄 index.js // 'sign-in' 페이지의 공개 API
📂 article-read/
📄 index.js // 'article-read' 페이지의 공개 API
📂 shared/
📂 ui/
📄 index.js // 'ui' 세그먼트의 공개 API
📂 api/
📄 index.js // 'api' 세그먼트의 공개 API이렇게 구성하면, pages/feed나 shared/ui 안의 세부 파일들은 외부에서 직접 접근할 수 없다. 따라서 외부에서는 index.js로 지정된 공개 API만 가져올 수 있으며, 해당 폴더의 세부 구조는 알 필요가 없어 코드 구조가 깔끔하게 유지된다.
📌 결론
Feature-Sliced Design(FSD)는 대규모 프론트엔드 애플리케이션의 유지보수성과 확장성을 높이기 위해 고안된 아키텍처 방법론이다. FSD의 기본 개념과 원칙, 그리고 사용 시의 이점을 정리하면 다음과 같다.
💡 FSD의 핵심 원칙
- 기능 중심의 코드 분할: 애플리케이션을 기능 단위로 나누어 관리하여 비즈니스 요구사항이 변경되어도 해당 기능만 집중적으로 수정할 수 있도록 설계되었다.
- 단방향 의존성: 상위 레이어는 하위 레이어만 참조할 수 있어, 코드의 결합도를 낮추고 특정 레이어의 변경이 다른 레이어로 확산되는 것을 방지한다.
- 재사용성과 독립성: 공통 기능이나 유틸리티는
Shared레이어에 두어 여러 레이어에서 재사용 가능하게 하고, 각 슬라이스는 독립적으로 관리하여 유지보수성을 높인다.
💡 FSD의 사용 시 이점
- 코드 가독성 및 관리 용이성: 코드가 기능별로 구조화되어 있어, 프로젝트가 커지더라도 필요한 기능이나 코드를 찾기 쉽다.
- 확장성: 새 기능이나 비즈니스 로직 추가 시 기존 코드와 독립적으로 개발할 수 있어 빠르고 유연하게 확장 가능하다.
- 유지보수성: 슬라이스와 레이어별로 코드가 모듈화되어 있어 변경 사항을 특정 부분에만 적용할 수 있어, 수정과 유지보수가 용이하다.
💡 FSD의 주요 규칙들
- 계층화된 레이어 구조: 프로젝트는
App,Pages,Widgets,Features,Entities,Shared로 구분된 레이어로 구성되며, 각 레이어는 고유한 역할을 가진다. - 슬라이스의 독립성: 슬라이스는 비즈니스 도메인별로 구성되며, 같은 레이어의 다른 슬라이스와 의존성을 가지지 않는다. 이를 통해 높은 응집도와 낮은 결합도를 유지한다.
- 엄격한 공개 API 관리: 슬라이스와 세그먼트는 외부에 노출할 부분만 명확히 선언하여 공개 API로 제공한다. 이를 통해 코드 구조가 명확해지고, 각 모듈이 독립성을 유지할 수 있다.
FSD 도입을 위한 도구들
FSD는 실제 개발 과정과 아키텍처 도입을 지원하기 위한 다양한 도구들을 공식적으로 제공한다. 프로젝트 아키텍처 검증을 위한 린터, CLI와 IDE 기반 폴더 생성기, 다양한 예제 라이브러리 등을 통해 FSD가 생소하거나 접근하기 어렵게 느껴질 경우에도 보다 쉽게 적용할 수 있도록 돕는다. 이미 FSD 아키텍처를 사용 중이라면 이러한 도구들을 활용하여 더욱 편리하게 개발을 진행할 수도 있다.
미친 고퀄리티 글 감사합니다.