clean-architecture

Original：🇺🇸 English

Translated

Guidelines for implementing Clean Architecture patterns in Flutter and Go applications, with emphasis on separation of concerns, dependency rules, and testability.

1installs

Sourcemindrally/skills

Added on2026-02-07

NPX Install

npx skill4agent add mindrally/skills clean-architecture

SKILL.md Content

View Translation Comparison →

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:

Domain Layer (innermost) - Business logic and entities
Application Layer - Use cases and application-specific logic
Infrastructure Layer - External concerns (databases, APIs, frameworks)
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