flutter 모듈화

선택 가이드 

• 소규모 프로젝트: 플랫 구조로 빠르게 시작.
• 중형 프로젝트: 기능별 모듈화로 팀 작업 효율화.
• 대규모 프로젝트: 레이어별 또는 도메인별로 구조적 안정성 확보.
• Clean Architecture: 레이어별 모듈화 추천.
• 비즈니스 중심: 도메인별 모듈화로 도메인 독립성 강화.

팁

• 의존성 주입: get_it 또는 Provider로 모듈 간 의존성 관리.
• 명명 규칙: 파일은 snake_case(예: login_screen.dart), 클래스는 PascalCase(예: LoginScreen).
• 테스트: 각 모듈에 테스트 폴더 추가(예: features/auth/tests/).
• 공통 모듈: core 또는 common으로 상수, 유틸리티, 테마 관리.

---

🔷 명칭 : 기능별 모듈화 (Feature-based)

파일 구조

lib/
├── core/
│   ├── constants/
│   └── utils/
└── features/
    ├── auth/
    │   ├── models/
    │   ├── providers/
    │   ├── screens/
    │   ├── services/
    │   └── widgets/
    └── profile/
        └── (유사 구조)

폴더별 사용처 및 포함 파일

• models: 기능별 데이터 구조 정의 (user.dart, post.dart)
• providers: 기능별 상태 관리 (auth_provider.dart, profile_provider.dart)
• screens: 기능별 화면 UI (login_screen.dart, profile_screen.dart)
• services: 기능별 API 및 비즈니스 로직 (auth_service.dart)
• widgets: 기능별 공용 위젯 (auth_button.dart)
• core/constants: 앱 전역 상수 (app_colors.dart)
• core/utils: 공통 유틸리티 (date_format.dart, validators.dart)

장점

• 기능 단위로 분리되어 독립성과 팀 작업 효율성 우수
• 기능 변경 시 영향 범위가 제한적
• 테스트 및 코드 유지보수 용이

단점

• 폴더 구조가 깊어져 탐색 복잡
• 작은 프로젝트에서 오버엔지니어링 가능성 있음
• 동일한 역할의 파일들이 흩어져 있어 횡단 관심사 파악이 어려움

설명

앱의 기능 단위(예: 인증, 프로필, 게시물 등)를 독립적인 폴더로 나누고, 해당 폴더 내에 models, providers, screens, services, widgets를 포함하는 구조이다. 공통 로직이나 상수는 core 폴더로 따로 분리하여 재사용성을 높인다. 중형 이상의 프로젝트나 팀 개발에 적합하며, 기능별 개발/배포가 유리하다.

---

 

🔷 명칭 : 레이어별 모듈화 (Layer-based)

파일 구조

lib/
└── src/
    ├── data/
    │   ├── models/
    │   └── services/
    ├── domain/
    │   └── providers/
    └── presentation/
        ├── screens/
        └── widgets/

폴더별 사용처 및 포함 파일

• data/models: 데이터 구조 정의 (user.dart, post.dart)
• data/services: API 통신, DB 접근 등 (api_service.dart, local_storage.dart)
• domain/providers: 상태 관리 및 비즈니스 로직 (user_provider.dart, auth_controller.dart)
• presentation/screens: UI 구성 화면 (home_screen.dart, login_screen.dart)
• presentation/widgets: 공통 UI 컴포넌트 (custom_button.dart, profile_card.dart)

장점

• 계층 간 책임 분리가 명확
• 테스트, 리팩토링에 유리
• Clean Architecture 구조와 호환 쉬움

단점

• 학습 곡선이 존재함
• 계층 간 이동이 잦아 작업 속도 저하
• 작은 프로젝트에선 과도한 구조

설명

기능이 아닌 "역할(계층)"에 따라 코드를 분리하는 방식으로, Clean Architecture와 유사하다. data(데이터 원천), domain(로직), presentation(UI) 구조로 구성되며, 대규모 앱에서 유지보수성과 확장성을 확보하는 데 유리하다.

---

🔷 명칭 : 도메인별 모듈화 (Domain-driven)

파일 구조

lib/
├── common/
│   ├── constants/
│   ├── utils/
│   └── widgets/
└── domain/
    ├── user/
    │   ├── models/
    │   ├── providers/
    │   ├── screens/
    │   ├── services/
    │   └── widgets/
    └── product/
        └── (유사 구조)

폴더별 사용처 및 포함 파일

• models: 도메인별 데이터 구조 (user.dart, product.dart)
• providers: 도메인별 상태 관리 (user_provider.dart, product_provider.dart)
• screens: 도메인별 UI (user_screen.dart, product_detail_screen.dart)
• services: 외부 연동, 비즈니스 로직 (user_service.dart, product_service.dart)
• widgets: 도메인 내 UI 컴포넌트 (user_card.dart, product_tile.dart)
• common: 공통 상수, 유틸, 재사용 UI (app_colors.dart, custom_button.dart)

장점

• 도메인 단위로 독립성이 높아 유지보수 용이
• 비즈니스 변화에 유연하게 대응 가능
• 확장 시 모듈 간 충돌 최소화

단점

• 도메인 경계가 불분명할 경우 설계 혼란
• 공통 코드가 분산될 위험 있음
• 초기 구조 설계 시간 증가

설명

앱의 비즈니스 영역을 기준으로 폴더를 나누는 방식으로, 마이크로서비스 아키텍처와 유사하다. 각 도메인은 자체 구조를 갖고 독립적으로 동작하므로, 도메인 단위 개발 및 분리 배포에 적합하다.

---

🔷 명칭 : 플랫 구조 (Flat)

파일 구조

lib/
├── models.dart
├── providers.dart
├── screens.dart
├── services.dart
└── widgets.dart

폴더별 사용처 및 포함 파일

• models.dart: 모든 모델 클래스 정의 (User, Post)
• providers.dart: 전체 앱 상태 관리 로직
• screens.dart: 앱의 모든 화면 위젯
• services.dart: API 호출, 로컬 저장소 등
• widgets.dart: 재사용 UI 위젯 모음

장점

• 구조가 단순하고 진입장벽이 낮음
• 빠른 개발 및 프로토타입 제작에 적합
• 설정이 거의 필요 없음

단점

• 프로젝트가 커질수록 유지보수 어려움
• 관련 코드가 흩어져 추적이 어려움
• 기능 확장 시 구조 재편 필요

설명

별도 폴더 없이 주요 로직을 단일 파일 또는 최소한의 파일로 나누어 배치하는 방식이다. 소규모 프로젝트나 데모, 단기성 앱에 적합하며, 규모가 커지면 기능별 또는 계층 구조로 리팩토링이 필요하다.