이 글은 https://docs.flutter.dev/app-architecture/case-study 이 페이지를 정리했습니다.
코드를 구성하는 인기있는 방법은 크게 2가지로 구분될 수 있습니다.
- 기능별
각 기능에 필요한 클래스가 함께 그룹화됩니다. 예를들어 auth 디렉토리에 auth_viewmodel.dart,, login_usecase.dart, logout_usecase.dart, login_screen.dart, logout_button.dart 와 같이 공통된 기능과 관련된 파일들을 넣을 수 있습니다. - 유형별
같은 타입의 파일들끼리 그룹화하는 방법입니다. 예를들어 repositories, models, services, viewmodels와 같은 디렉토리를 만들고 하위에 해당 디렉토리에 해당하는 파일들만 그룹화 시킬 수 있습니다.
추천하는 아키텍처는 두 가지 방법을 결합하는 것인데, 데이터 계층 객체(repossitories, services)는 하나의 기능에 연관되지 않지만 UI계층 객체(view, view-modelss)는 하나의 기능으로 그룹화할 수 있습니다.
- 데이터 계층 객체 - 유형별
- UI 계층 객체 - 기능별
폴더 구조 예시입니다.
lib
|____ui
| |____core
| | |____ui
| | | |____<shared widgets>
| | |____themes
| |____<FEATURE NAME>
| | |____view_model
| | | |_____<view_model class>.dart
| | |____widgets
| | | |____<feature name>_screen.dart
| | | |____<other widgets>
|____domain
| |____models
| | |____<model name>.dart
|____data
| |____repositories
| | |____<repository class>.dart
| |____services
| | |____<service class>.dart
| |____model
| | |____<api model class>.dart
|____config
|____utils
|____routing
|____main_staging.dart
|____main_development.dart
|____main.dart
// The test folder contains unit and widget tests
test
|____data
|____domain
|____ui
|____utils
// The testing folder contains mocks other classes need to execute tests
testing
|____fakes
|____models
data 폴더는 리포지토리와 서비스를 여러 기능과 여러 뷰 모델에서 사용할 수 있기 때문에 코드를 유형별로 구성합니다.
ui 폴더는 각 기능에 정확히 하나의 뷰와 정확히 하나의 뷰 모델이 있기 때문에 코드를 기능별로 구성합니다.
위 구조의 다른 특징들입니다.
- UI 폴더에는 "core"라는 하위 디렉토리도 있습니다. Core에는 브랜드 스타일이 적용된 버튼과 같이 여러 뷰에서 공유하는 위젯과 테마 로직이 들어 있습니다.
- 도메인 폴더에는 애플리케이션 데이터 유형이 들어 있습니다. (데이터 및 UI 계층에서 사용되므로)
- 앱에는 개발, 스테이징, 프로덕션을 위한 애플리케이션의 다양한 진입점 역할을 하는 세 개의 "main" 파일이 포함되어 있습니다.
- 두 개의 테스트 관련 디렉토리가 있습니다 test/ 하위에는 테스트 코드가 있으며, 그 구조는 lib/ 디렉토리와 동일한 구조입니다.
testing/는 다른 패키지의 테스트 코드에서 사용할 수 있는 mock 객체 및 기타 테스트 유틸리티를 포함하는 하위 패키지입니다.
testing/ 폴더는 실제 프로덕션 환경에는 배포되지 않는, 테스트 전용 버전의 앱이라고 볼 수 있습니다. 테스트의 대상이 되는 코드가 포함되어 있습니다. 즉, test/는 테스트를 실행하는 코드가 있고, testing/은 테스트에 필요한 도구와 테스트 대상이 되는 코드가 있다고 이해하시면 됩니다.
샘플 앱의 UI는 뷰 모델과 ChangeNotifier를 주로 사용했지만, 다음과 같은 다른 방식으로도 쉽게 작성될 수 있었습니다:
- 스트림 사용
- riverpod, flutter_bloc, signals 같은 다른 라이브러리 사용
이 앱의 레이어 간 통신은 새로운 데이터를 폴링하는 것을 포함해 모든 것을 메소드 호출로 처리했습니다. 하지만 이 가이드의 규칙을 지키면서도 저장소(repository)에서 뷰 모델로 데이터를 노출할 때 스트림을 사용할 수도 있었을 것입니다.