Перейти на PRO

Расскажите о вашем опыте применения Чистой Архитектуры (Clean Architecture) в Go-проектах.

Тип вопроса: Архитектура Вероятность: 10% Категория: Golang Разработчик

Ответ

Да, я знаком и применяю принципы Чистой Архитектуры. Она помогает создавать слабосвязанные, тестируемые и легко поддерживаемые системы, что особенно ценно в долгосрочных проектах.

Главный принцип — правило зависимостей (Dependency Rule): все зависимости направлены внутрь, к ядру бизнес-логики. Внешние слои (БД, UI, фреймворки) зависят от внутренних, но не наоборот.

Типичная структура слоев в Go-проекте:

  1. Entities (Сущности): Ядро приложения. Это структуры Go, описывающие бизнес-объекты (например, User, Order). Они не зависят ни от чего.

  2. Use Cases (Сценарии использования): Содержат бизнес-логику приложения. Определяют интерфейсы для работы с данными (UserRepository) и реализуют сценарии (UserService), которые зависят только от этих интерфейсов.

  3. Interface Adapters (Адаптеры интерфейсов): Преобразуют данные из формата, удобного для внешних систем (HTTP, gRPC), в формат, удобный для Use Cases, и обратно. Сюда входят контроллеры, презентеры и репозитории.

  4. Frameworks & Drivers (Инфраструктура): Внешний слой. Конкретные реализации: веб-сервер (net/http), драйверы БД (pq, mongo-driver), клиенты внешних API. Этот слой реализует интерфейсы, определенные в Use Cases.

Пример реализации с инверсией зависимостей:

// usecase/user.go (внутренний слой)
package usecase

// Интерфейс репозитория, не знает о БД
type UserRepository interface {
    GetByID(ctx context.Context, id int) (*entity.User, error)
}

// ... UserService, который использует UserRepository ...

// -----------------------------------------------------

// repository/user_postgres.go (слой адаптеров/инфраструктуры)
package repository

// Конкретная реализация для PostgreSQL
type UserPostgresRepo struct {
    db *sql.DB
}

// Метод реализует интерфейс из usecase
func (r *UserPostgresRepo) GetByID(ctx context.Context, id int) (*entity.User, error) {
    // ... логика запроса к PostgreSQL ...
}

// -----------------------------------------------------

// main.go (сборка зависимостей)
func main() {
    db := connectToDB()

    // Внедрение зависимости: конкретная реализация передается туда,
    // где ожидается интерфейс.
    userRepo := repository.NewUserPostgresRepo(db)
    userService := usecase.NewUserService(userRepo)
    httpHandler := delivery.NewHandler(userService)

    // ... запуск сервера ...
}

Преимущества:

  • Независимость от фреймворков и БД: Можно заменить PostgreSQL на MongoDB, не меняя бизнес-логику.
  • Высокая тестируемость: Легко подменять зависимости (мокать) в тестах.
  • Гибкость и масштабируемость: Код проще изменять и расширять.

Недостатки:

  • Больше кода (boilerplate): Требует создания множества интерфейсов и структур.
  • Избыточность для простых проектов: Может усложнить небольшие CRUD-сервисы.

Я использую этот подход для сложных и долгоживущих проектов, где важна гибкость и поддерживаемость.

Ответ 18+ 🔞

Да ты посмотри, какие мы архитектурные выёбки придумали, блядь! Чистая Архитектура, ёпта! Это ж не просто так, чтобы код писать, а чтобы потом, когда через год захочешь поменять базу данных, не пришлось бы всю свою ебучую систему переписывать, а просто, блядь, один адаптер подкрутить и всё!

Главная фишка, на которую надо смотреть как на икону — правило зависимостей. Представь себе матрёшку, только наоборот. Внутри, в самой сердцевине — святая святых, бизнес-логика. А всё остальное — базы, веб-сервера, эти ваши фреймворки — это как бы внешние слои, которые зависят от центра, а не наоборот. Центру на них, в общем-то, похуй.

Как это обычно в Go выглядит, слоями:

  1. Сущности (Entities): Это типа святые мощи приложения. Структуры User, Order. Они просто есть, они не знают ни про какой PostgreSQL или HTTP. Чистая бизнес-правда.

  2. Сценарии использования (Use Cases): Тут уже мозги. Вся логика: «создать пользователя», «отменить заказ». Они знают, что им нужны какие-то данные, но не знают, откуда они берутся. Поэтому они объявляют интерфейсы: «эй, мир, мне нужен кто-то, кто умеет давать пользователя по ID». И всё.

  3. Адаптеры (Interface Adapters): Это переводчики, блядь. Берут сырые данные из внешнего мира (JSON из HTTP, строки из БД) и переводят их на язык, который понимают Use Cases. Контроллеры, репозитории — они тут.

  4. Инфраструктура (Frameworks & Drivers): А это уже реальный мир, полный говна и проблем. Конкретный PostgreSQL драйвер, конкретная библиотека для HTTP-роутинга. Этот слой идёт и реализует те интерфейсы, которые Use Cases нарисовали.

Смотри, как это в коде выглядит, чтобы не быть просто пиздаболом:

// usecase/user.go (ядро, бизнес)
package usecase

// Интерфейс репозитория. Это как договор: "я хочу уметь получать юзера по айди".
// Где и как — не ебу, это твои проблемы.
type UserRepository interface {
    GetByID(ctx context.Context, id int) (*entity.User, error)
}

// ... Дальше UserService, который этот интерфейс использует ...

// -----------------------------------------------------

// repository/user_postgres.go (внешний слой, реализация)
package repository

// Конкретная реализация для PostgreSQL. Она ЗАВИСИТ от интерфейса из ядра.
type UserPostgresRepo struct {
    db *sql.DB
}

// Смотри, сука, метод! Он РЕАЛИЗУЕТ интерфейс usecase.UserRepository.
// Ядро сказало "подай мне того, кто умеет GetByID", а этот тип говорит "я умею!".
func (r *UserPostgresRepo) GetByID(ctx context.Context, id int) (*entity.User, error) {
    // ... вот тут уже реальный запрос `SELECT * FROM users` ...
}

// -----------------------------------------------------

// main.go (сборка, тут всё склеивается)
func main() {
    db := connectToDB() // Подключение к реальной базе, с паролями и портами.

    // Магия инверсии зависимостей! Мы берём конкретную реализацию (Postgres)
    // и передаём её туда, где ожидается абстракция (интерфейс UserRepository).
    userRepo := repository.NewUserPostgresRepo(db)
    userService := usecase.NewUserService(userRepo) // Сервису похуй, что там внутри.
    httpHandler := delivery.NewHandler(userService)

    // ... и поехали ...
}

Что хорошего, спросишь?

  • Независимость, ёбта! Захотел с PostgreSQL на MongoDB переехать? Пожалуйста! Пишешь новую реализацию UserMongoRepo, которая тоже реализует UserRepository, подменяешь в main.go — и бизнес-логика даже не чихнула. Она нихуя не знает про смену базы.
  • Тестировать — одно удовольствие. В тестах вместо реальной базы подсовываешь заглушку (mock), которая реализует тот же интерфейс, и проверяешь чистую логику.
  • Масштабируется легче. Мозги отдельно, детали отдельно. Менять что-то одно не разваливает всё остальное.

А что плохого?

  • Кода — овердохуища. Надо эти интерфейсы плодить, структуры, адаптеры. Для простенького CRUD-сервиса на три экрана — это как из пушки по воробьям, чистое распиздяйство.
  • Сложность. Новому челу надо время, чтобы въехать, почему тут столько слоёв и куда что класть.

Я эту архитектуру применяю, когда проект не пет-проджект на неделю, а что-то серьёзное, что будет жить годами и обрастать фичами. Когда понимаешь, что сегодня Postgres, а завтра могут попросить часть данных в Kafka пихать. А так — да похуй, иногда проще на чистом голом sql.DB написать и не париться. Всё от задачи зависит, чувак.

© ХакСобесов, 2026
support@hacksobesov.com