Feature-Sliced Design 으로 프론트엔드 애플리케이션을 스캐폴딩하기 위한 아키텍처 방법.
간단히 말해, 코드 구성에 관한 규칙의 모음이다. 이 방법론의 주된 목적은 끊임없이 변화하는 비즈니스 요구사항에 맞서 프로젝트를 더 이해하기 쉽고 체계적으로 만드는 것이다.
웹 프론트엔드 기술에는 잘 알려져서 많은 기업들이 사용하고 있는 반면, 앱 개발에서는 자료를 찾기힘들었음
각 레이어는 독립적인 레이어로 계층마다 접근할 수 있는 레어어가 분리되어있음
App : 애플리케이션 및 그 종속 항목을 초기화하는 곳입니다. 이것이 모든 것의 시작점입니다. 여기서 저는 애플리케이션의 "모듈"을 명시적으로 반영하며, 페이지, 경로, 기능 및 엔티티가 모두 조직되는 애플리케이션의 계층입니다.
Pages : 이 계층에는 앱의 페이지가 포함되어 있습니다. 이것은 플러터 세계에서 위젯 트리의 시작점이며 사용자에게 제공되는 기능 및 데이터의 진입점입니다.
Widgets : 기능적으로 그리고 그래픽적으로 "진화한" 구성 요소(사용자 인터액션 + UI 요소)로, 다른 3개의 하위 계층에서 기본 구성 요소를 조립합니다.
Features : 사용자에게 가치를 제공하는 기능 시나리오와 사용 사례입니다. 예를 들어, 콘텐츠 공유, 댓글 작성, "게시물" 평가 등이 있습니다.
Entities : "게시물", "댓글", "기사"와 같은 비즈니스 엔티티입니다. 이 계층은 각 엔티티에 맞게 맞춰진 "scaffold" 타입 위젯을 포함하며, 예를 들어 테이블에서 "게시물"을 나타내는 "Card"나 목록에서 "댓글"을 나타내는 "Tile"이 있습니다("scaffold"은 상위 계층의 위젯과 기능을 위한 슬롯을 제공합니다).
Shared : 특정 비즈니스 로직에 종속되지 않은 재사용 가능한 구성 요소 및 유틸리티입니다(기본 위젯, API, 익스텐션, 유틸리티 등).
첫번쨰 그림을 보면 Can Use, Can be Used By 두 가지로 분류 되는데 예를 들어 설명해보겠음
App 레이어 에서는 Shared, Entities, Features, Widgets, Page 해당 레이어를 참조 할 수 있으며, 다른곳에서 App 레이어를 참조하여 사용할 수 없다.
이렇게 분리된 레이어는 서로 정해진 규약이 있으며, 아래의 이점을 얻는다.
- 팀 간 워크플로 및 협업의 속도 향상
- 최종 제품이 사용자 요구 사항과 더 잘 맞도록 합니다.
- 변화에 대한 더 큰 적응력
- 새로운 기능의 더 쉬운 구현
- 기존 시스템의 변경으로 인한 간섭이 최소화됩니다.
또한 이러한 장점은 MVP를 빠르게 런칭시킬수 있으며, 기존의 구조에 해를 끼치지 않으면서 개발할 수 있다는 또 다른 결과를 만들어낸다.
그렇지만 분명히 단점도 존재한다. 초기 프로젝트를 세팅할 때 프로젝트의 구조를 짜기가 힘들다는 부분이있다.
하지만 처음에 구조를 잘 설계하여 개발을 한다면 차후에 기능 추가/삭제를 할 때 용이할것이다.
https://feature-sliced.design/ 이 사이트에서 FSD아키텍쳐를 사용한 예시들을 찾아볼 수 있다(현재 Flutter Project는 없으며 주로 웹 개발에서 사용되고 있음)
만약 기존에 사용하던 프로젝트 구조에서 FSD로 Migration한다면, FSD 규칙을 위반하는 내용이 있더라도 위젯과 페이지에 분산 후 차근차근 하는것을 추천한다.