architecture_skill

Overview

This skill codifies a feature-first Clean Architecture pattern for Flutter/Dart projects, focused on practical simplifications: BLoC → repository interfaces and DTOs shared across layers by default. It provides clear rules for organizing feature slices, deciding when to extract packages, and handling DTO generation and serialization. The goal is stable, testable features with minimal ceremony.

How this skill works

The skill inspects feature structure and enforces dependency direction: presentation imports only domain, domain is pure Dart, and data contains I/O and DTOs. It guides creation of feature folders, domain repository contracts, data implementations, and DTO serialization directives. It also advises when to extract shared code into packages and when to split API models from domain models.

When to use it

• Creating a new feature (UI + domain + data) in a Flutter app.
• Adding or updating DTOs and their serialization logic.
• Refactoring violations of dependency direction (presentation importing data).
• Deciding whether shared code should live in a feature or be extracted to a package.
• Implementing repository interfaces and data-layer error translation.

Best practices

• Keep domain minimal and stable: only interfaces and DTO types, no Flutter imports.
• Use DTOs across layers by default; split models only for concrete reasons (stability, invariants, privacy).
• Place presentation wiring in <Feature>Screen and UI in <Feature>View for easy testing.
• Generate immutable DTOs with the Dart Data Class Generator and include explicit $from/$to directives for nonstandard fields.
• Extract code to packages only when reused across features or needing independent tests (clients, cross-feature models, core utilities).
• Expose public surfaces with barrel files and avoid exporting internal-only files.

Example use cases

• Create an Orders feature: define IOrdersRepository in domain, OrderDto in data/models, and an OrdersRepository implementation.
• Add a DateTime or Duration field with $from/$to directives to handle serialization consistently.
• Refactor a feature where presentation imports a data class—move the DTO/interface into domain to restore proper dependency direction.
• Extract a shared api_client and typed preferences into a package used across multiple features.
• Decide to keep API DTOs as-is unless the external model is unstable or domain invariants require a separate domain model.