Применяешь ли чистую архитектуру

Применяю чистую архитектуру Роберта Мартина (Clean Architecture) и считаю ее одним из наиболее эффективных подходов для создания масштабируемых, тестируемых и гибких приложений на Go, особенно в долгосрочной перспективе. Однако применяю не догматично, а адаптирую принципы под специфику Go и конкретного проекта. Вот как это выглядит на практике.

Почему чистую архитектуру стоит применять в Go

Go — язык с простым синтаксисом, но без классического ООП (наследования, классов). Это иногда приводит к размыванию ответственности в больших проектах. Чистая архитектура помогает:

• Изолировать бизнес-логику от фреймворков, баз данных и внешних сервисов.
• Упростить тестирование благодаря зависимости от абстракций (интерфейсов Go).
• Обеспечить долгосрочную гибкость — замена базы данных, HTTP-фреймворка или даже UI-слоя требует минимальных изменений в ядре.
• Сделать код предсказуемым за счет четкого правила зависимостей, направленных внутрь, к ядру.

Базовая структура слоев в Go-проекте

Реализация чаще всего состоит из четырех концентрических слоев.

// 1. **Entities (Сущности)** - Ядро бизнес-логики
package entity

type User struct {
    ID        uuid.UUID
    Email     string
    // Важно: нет аннотаций JSON или тегов БД!
}

type UserService interface {
    Register(email, password string) (*User, error)
}

// 2. **Use Cases (Сценарии использования)** - Применение сущностей для решения бизнес-задач
package usecase

import "myapp/entity"

// Интерфейс репозитория определен в том же слое usecase или в entity
type UserRepository interface {
    Save(user *entity.User) error
    FindByEmail(email string) (*entity.User, error)
}

// Реализация Use Case зависит только от интерфейсов
type RegisterUseCase struct {
    repo    UserRepository
    hasher  PasswordHasher // Еще один интерфейс!
}

func (uc *RegisterUseCase) Execute(email, pass string) (*entity.User, error) {
    // Вся бизнес-логика и валидация здесь
    if err := validateEmail(email); err != nil {
        return nil, entity.ErrInvalidEmail
    }
    // ...
}

// 3. **Interface Adapters (Адаптеры)** - Преобразование данных между слоями
package adapter

import (
    "myapp/usecase"
    "github.com/gin-gonic/gin"
)

// HTTP Handler (Контроллер) - адаптирует HTTP-запросы к Use Case
type HTTPHandler struct {
    registerUC usecase.RegisterUseCase
}

func (h *HTTPHandler) Register(c *gin.Context) {
    var req RegisterRequest
    if err := c.BindJSON(&req); err != nil {
        c.JSON(400, gin.H{"error": err.Error()})
        return
    }
    // Вызов Use Case (ядра приложения)
    user, err := h.registerUC.Execute(req.Email, req.Password)
    // Адаптация ответа ядра к HTTP
    c.JSON(201, ToResponse(user))
}

// Реализация репозитория (например, для PostgreSQL)
type PostgreSQLUserRepository struct {
    db *sql.DB
}

func (r *PostgreSQLUserRepository) Save(user *entity.User) error {
    // Здесь и только здесь появляются SQL-запросы
    _, err := r.db.Exec("INSERT INTO users...", user.ID, user.Email)
    return err
}

// 4. **Frameworks & Drivers (Внешний мир)** - Инициализация фреймворков
package main

import (
    "database/sql"
    "myapp/adapter"
    "myapp/usecase"
    _ "github.com/lib/pq" // Драйвер БД
)

func main() {
    // 1. Подключаем БД (внешнее)
    db, _ := sql.Open("postgres", "connection_string")
    // 2. Создаем реализацию адаптера (репозиторий)
    repo := &adapter.PostgreSQLUserRepository{db: db}
    // 3. Инжектируем зависимости в Use Case (ядро)
    useCase := &usecase.RegisterUseCase{repo: repo}
    // 4. Создаем HTTP-обработчик, передавая ядро
    handler := &adapter.HTTPHandler{registerUC: useCase}
    // 5. Настраиваем фреймворк (Gin) с нашим адаптером
    r := gin.Default()
    r.POST("/register", handler.Register)
    r.Run()
}

Ключевые принципы в Go-реализации

• Зависимость от абстракций (интерфейсов Go): Use Case зависит от UserRepository, а не от конкретной PostgreSQLUserRepository. Это позволяет легко подменять реализации (например, на in-memory для тестов).
• Инверсия зависимостей (DIP): Интерфейсы репозитория объявляются во внутреннем слое (в usecase), а их реализации — во внешнем (adapter). Так направление зависимостей остается внутрь.
• Простая композиция: Вместо наследования используется композиция структур и встраивание (embedding) в Go.
• Чистые функции: Бизнес-логика в Use Cases старается быть чистой (детерминированной, без побочных эффектов), что упрощает тестирование до уровня юнит-тестов без моков БД или HTTP.

Когда применение оправдано, а когда — нет

Применяю обязательно:

• В сложных domain-driven проектах (финансы, e-commerce).
• В долгосрочных проектах, где требования часто меняются.
• В командной разработке, чтобы четко разделить ответственность.

Упрощаю или не применяю:

• В микросервисах с простой логикой (CRUD-апи) — можно ограничиться гексагональной архитектурой (ports & adapters).
• В прототипах или скриптах — overhead архитектуры убивает скорость.
• В высоконагруженных системах, где критична микрооптимизация — иногда прямой доступ к БД из хендлера дает выигрыш.

Адаптация под Go-идиомы

В Go я избегаю сложных абстракций и овер-инжиниринга. Например:

• Интерфейсы определяю близко к месту использования, а не в гигантских ports пакетах.
• Сущности (Entities) — это часто простые struct с методами-валидаторами, а не "классы" с поведением.
• Dependency Injection делаю через явную передачу зависимостей в конструкторах, без тяжелых контейнеров, если проект небольшой.

Заключение

Чистую архитектуру в Go применяю как стратегический каркас, а не как догму. Она дает команде общий язык и предотвращает превращение кода в спагетти-код. Главное — соблюсти баланс между чистотой дизайна и прагматизмом Go, не добавляя слоев абстракции там, где в них нет реальной необходимости. В результате получается понятный, поддерживаемый и надежный код, который легко развивать даже спустя годы.