layered-architecture

Structures Flutter monorepos into four unidirectional layers with independent Dart packages.

162|23|Updated Feb 27, 2026
One-click install
npx skills add https://github.com/VeryGoodOpenSource/vgv-ai-flutter-plugin --skill layered-architecture-verygoodopensource
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: layered-architecture
Source: https://github.com/VeryGoodOpenSource/vgv-ai-flutter-plugin/tree/main/skills/layered-architecture
Command: npx skills add https://github.com/VeryGoodOpenSource/vgv-ai-flutter-plugin --skill layered-architecture-verygoodopensource

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Flutter apps often grow into tangled codebases where widgets call APIs directly, business logic mixes with UI, and API response shapes leak into the domain. This Skill enforces VGV's layered monorepo architecture so every feature follows strict Data, Repository, Business Logic, and Presentation boundaries. ## Core Features & Use Cases - Four-Layer Architecture: Defines Data, Repository, Business Logic, and Presentation layers with unidirectional dependencies (Presentation → Business Logic → Repository → Data) that can never be skipped or inverted. - Monorepo Package Layout: Data and Repository layers live as independent Flutter-free Dart packages in packages/ with path dependencies, barrel exports, and constructor-injected clients. - Model Transformation: Separates API response models from Equatable domain models, with transformation patterns, nullable-field handling, and multi-source composition. - Use Case: When starting a weather app that reads from a REST API, use this Skill to lay out the package structure, scaffold weather_api_client and weather_repository packages, and wire everything through RepositoryProvider in the app bootstrap. ## Quick Start Ask the assistant to lay out the package structure for a new Flutter app that talks to a REST API using the layered architecture.

Frequently Asked Questions about layered-architecture

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I structure a Flutter monorepo with layered architecture?

Organize the app into four layers: Data and Repository layers as independent Dart packages under packages/, and Business Logic plus Presentation under lib/ by feature. Dependencies flow one way only: Presentation to Business Logic to Repository to Data, connected with path dependencies in pubspec.yaml.

Where should domain models live in a Flutter layered architecture?

Domain models live in the repository package, not the data package. Data packages contain response models matching the API schema, while the repository transforms them into Equatable domain models so API changes never leak into business logic or UI.

Can a Flutter repository package depend on another repository?

No, repositories never import other repositories. Each repository is self-contained and combines data sources through constructor-injected data clients; if data from multiple repositories is needed, combine it at the Bloc level instead.

Why use path dependencies instead of pub versions in a Flutter monorepo?

Path dependencies let local packages update instantly without publish or push cycles. Using git or pub version references for packages in the same repo breaks the monorepo workflow and slows iteration.

Can data layer packages import Flutter?

No, data and repository packages must not depend on the Flutter SDK. Scaffold them as pure Dart packages so they remain reusable in Dart-only contexts like CLI tools or servers, and inject platform dependencies through constructors.

How do I test repositories and data clients in isolation?

Mock only the immediate dependency: repository tests mock the data client with mocktail, and data client tests mock the HTTP client. Never mock two layers deep, and write explicit tests for every model transformation including nullable fields.