# Flutter Feature Based Clean Architecture

> Organize Flutter apps with modular feature-based clean architecture. Use when creating features under lib/features/ with domain, data, and presentation layers. Do not use for test-only, BlocBuilder, navigation, or spinner requests.

- Skill: `hoangnguyen0403/flutter-feature-based-clean-architecture` (Agent Skill, multi-file: 5 files)
- Install (CLI): `npx skillmds@latest add hoangnguyen0403/flutter-feature-based-clean-architecture`
- Raw SKILL.md: https://api.skillmd.com/api/skills/hoangnguyen0403/flutter-feature-based-clean-architecture/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: HoangNguyen0403 (https://skillmd.com/u/hoangnguyen0403)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/hoangnguyen0403/flutter-feature-based-clean-architecture

---

# Feature-Based Clean Architecture

## **Priority: P0 (CRITICAL)**


## Structure

Every feature lives in `lib/features/` with **3-layer separation** (domain/data/presentation):

- `domain/` — Entities, failures, and Repository interfaces.
- `data/` — DTOs, DataSource, and Repository implementations.
- `presentation/` — BLoC/Cubit, pages, and widgets.

See [references/folder-structure.md](references/folder-structure.md) for complete directory blueprint.

## Implementation Workflow

1. **Create feature directory** — Add new folder under `lib/features/` (e.g., `lib/features/promotions/`).
2. **Define domain layer** — Add entities, failures, and repository interfaces with zero external dependencies.
3. **Implement data layer** — Add DTOs, data sources, and repository implementations that depend only on Domain.
4. **Build presentation layer** — Add BLoC/Cubit, pages, and widgets that depend only on Domain.
5. **Enforce dependency rule** — `Presentation -> Domain <- Data`. Domain must zero external dependencies.
6. **Share cross-cutting logic** — Move reusable utilities to `lib/shared/` or `lib/core/`.

### Feature Directory Example

See [implementation examples](references/implementation.md) for full directory tree and cross-feature import patterns.

## Reference & Examples

For feature folder blueprints and cross-layer dependency templates:
See [references/REFERENCE.md](references/REFERENCE.md).

## Anti-Patterns

- **No Cross-Feature Data Imports**: Only import Domain types across features
- **No UI/Data in Domain Layer**: Never put UI or Data classes inside `domain/`
- **No Nested Features**: Keep `lib/features/` flat with no sub-feature directories
- **No Direct Repository Calls**: Use specific BLoCs or use-cases instead of calling other features' repositories directly from UI

## Related Topics

layer-based-clean-architecture | retrofit-networking | go-router-navigation | bloc-state-management | dependency-injection

## Canonical response anchors

When this skill applies, preserve the following domain terminology or equivalent concrete examples in the answer when relevant:
- entities) but never import from loyalty's data/ or presentation/ layers,entities

