---

name: clean-architecture description: Guidelines for implementing Clean Architecture patterns in Flutter and Go applications, with emphasis on separation of concerns, dependency rules, and testability. metadata: maintainer: Mindrally source: https://github.com/Mindrally/skills

Clean Architecture

You are an expert in Clean Architecture patterns for application development.

Core Principles

Clean Architecture enforces separation of concerns through distinct layers with dependencies pointing inward:

1. Domain Layer (innermost) - Business logic and entities
2. Application Layer - Use cases and application-specific logic
3. Infrastructure Layer - External concerns (databases, APIs, frameworks)
4. Presentation Layer (outermost) - UI and user interaction

The fundamental rule: inner layers must never depend on outer layers.

Flutter + Clean Architecture

Architecture Layers

• Presentation: Widgets, BLoCs, and UI components
• Domain: Entities, use cases, and repository interfaces
• Data: Repository implementations, data sources, and models

Feature-first Organization

feature/
  data/
    datasources/
    models/
    repositories/
  domain/
    entities/
    repositories/
    usecases/
  presentation/
    bloc/
    pages/
    widgets/

State Management with flutter_bloc

• Use flutter_bloc for state management
• Implement immutable states via Freezed
• Handle events and states with proper patterns
• Keep BLoCs focused on single responsibilities

Error Handling

• Implement Either<Failure, Success> pattern from Dartz
• Use functional error handling without exceptions
• Define clear Failure types for different error scenarios

Key Libraries

• flutter_bloc - State management
• freezed - Immutable classes and unions
• get_it - Service locator for DI
• dartz - Functional programming utilities

Go Backend Clean Architecture

Layer Separation

• Handlers - HTTP/gRPC request handling
• Services - Business logic and use cases
• Repositories - Data access abstractions
• Domain Models - Core business entities

Interface-driven Development

• Define interfaces for all dependencies
• Implement dependency injection through constructors
• Keep interfaces small and focused
• Allow easy mocking for tests

Project Structure

project/
  cmd/              # Application entry points
  internal/
    domain/         # Business entities and interfaces
    service/        # Business logic implementation
    repository/     # Data access implementation
    handler/        # HTTP/gRPC handlers
  pkg/              # Shared utilities

Testing Strategy

• Write table-driven unit tests with mocks
• Separate fast unit tests from integration tests
• Use interfaces to inject test doubles
• Achieve high coverage of business logic