чистая архитектура

Чистая архитектура (Clean Architecture) — это принцип организации кода, предложенный Робертом Мартином (Uncle Bob) в 2012 году. Суть: деловая логика приложения должна быть полностью независима от технических деталей — фреймворков, баз данных, UI, внешних сервисов. Эти детали — сменяемые «плагины», бизнес-правила — стабильное ядро системы.

Проблема, которую решает чистая архитектура

В типичном «спагетти-коде» бизнес-логика разбросана по контроллерам, SQL-запросам, обработчикам HTTP. Когда нужно сменить базу данных — переписывают половину приложения. Когда нужно протестировать бизнес-правило — поднимают весь стек с БД, HTTP-сервером, внешними API.

Чистая архитектура решает это строгим правилом зависимостей: зависимости направлены только внутрь. Внешние слои зависят от внутренних, никогда наоборот. Бизнес-логика не знает о существовании HTTP, SQL или конкретного фреймворка.

Концентрические слои

Entities (сущности)

Самое ядро. Объекты бизнес-домена с ключевыми бизнес-правилами. Не зависят ни от чего — ни от фреймворка, ни от БД, ни от UI. Могут использоваться в любом приложении, где нужна эта бизнес-логика.

Use Cases (сценарии использования)

Бизнес-логика конкретного приложения. Оркестрируют сущности, реализуют пользовательские сценарии: «Создать заказ», «Обработать платёж», «Зарегистрировать пользователя». Не зависят от фреймворка и БД, зависят только от сущностей.

Interface Adapters (интерфейсные адаптеры)

Конвертируют данные между форматом use cases и форматом внешнего мира. Контроллеры HTTP, презентеры, репозитории (интерфейс — здесь, реализация с SQL — снаружи). Знают о фреймворке и деталях представления, но не о деталях БД.

Frameworks & Drivers (фреймворки и драйверы)

Самый внешний слой: веб-фреймворк, ORM, UI, база данных, внешние API. Детали реализации. Этот слой максимально «грязный» — здесь пишут минимум кода, делегируя всё внутренним слоям.

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

Ключевое правило чистой архитектуры: исходный код может зависеть только от того, что находится в более внутреннем круге. Entity ни о чём внешнем не знает. Use case знает о сущностях. Адаптер знает о use cases. Фреймворк знает обо всём — но на него никто не ссылается изнутри.

Для соблюдения правила при необходимости «обратной» зависимости используют Dependency Inversion: use case определяет интерфейс репозитория (OrderRepository), конкретная реализация на SQL — во внешнем слое, инъектируется через DI-контейнер.

Связь с другими архитектурными подходами

Чистая архитектура — синтез и формализация нескольких родственных идей: Hexagonal Architecture (Ports and Adapters) Алистера Кокберна, Onion Architecture Джеффри Палермо. Все они выражают одну идею — ядро не знает о периферии — разными словами и схемами.

На практике: как выглядит структура проекта

Типичная структура директорий: domain/ (entities, value objects, domain services), application/ (use cases, application services, port interfaces), infrastructure/ (repository implementations, HTTP clients, email adapters), interfaces/ (HTTP controllers, CLI handlers, message consumers).

Тест бизнес-логики не требует базы данных: репозитории заменяются in-memory реализациями. Use case тестируется с mock-адаптерами за секунды.

Критика и ограничения

Чистая архитектура добавляет слои абстракции и бойлерплейт. Для простых CRUD-приложений это избыточно: DTO на каждом слое, интерфейсы репозиториев, маппинг между объектами разных слоёв — всё это увеличивает объём кода без видимой пользы.

Подход оправдан для систем со сложной, изменчивой бизнес-логикой, долгим жизненным циклом и большой командой. Для MVP или простых сервисов — прагматичный подход с меньшим числом слоёв предпочтительнее.

Чистая архитектура и микросервисы

Принципы чистой архитектуры применяются внутри каждого микросервиса независимо. Маленький микросервис может применять упрощённую версию — только use cases и адаптеры без полного набора слоёв. Главное — бизнес-логика не знает об HTTP и SQL.