Gymterview
middle

Что такое Clean Architecture (чистая архитектура)

Clean Architecture (чистая архитектура) — концепция, предложенная Робертом Мартином (Uncle Bob), в которой зависимости направлены только внутрь: внешние слои знают о внутренних, но внутренние не знают о внешних.

Диаграмма слоёв

Пример
┌──────────────────────────────────────────────────────────────┐
│                  Frameworks & Drivers                        │
│   (Spring, JPA, Kafka, REST, UI)                            │
│  ┌────────────────────────────────────────────────────────┐  │
│  │               Interface Adapters                       │  │
│  │   (Controllers, Gateways, Presenters)                  │  │
│  │  ┌──────────────────────────────────────────────────┐  │  │
│  │  │            Application Business Rules            │  │  │
│  │  │               (Use Cases)                        │  │  │
│  │  │  ┌────────────────────────────────────────────┐  │  │  │
│  │  │  │       Enterprise Business Rules            │  │  │  │
│  │  │  │          (Entities / Domain)               │  │  │  │
│  │  │  └────────────────────────────────────────────┘  │  │  │
│  │  └──────────────────────────────────────────────────┘  │  │
│  └────────────────────────────────────────────────────────┘  │
└──────────────────────────────────────────────────────────────┘

Зависимости → всегда направлены внутрь (к центру)

Слои

  • Entities (Сущности) — бизнес-объекты и правила, не зависящие ни от чего. Могут использоваться в любом приложении.
  • Use Cases (Сценарии использования) — специфическая бизнес-логика приложения. Оркестрируют сущности.
  • Interface Adapters (Адаптеры интерфейсов) — преобразование данных между форматом Use Case и внешним форматом (контроллеры, презентеры, маппинг).
  • Frameworks & Drivers — фреймворки, БД, веб-серверы и прочие внешние инструменты.

Правило зависимостей (Dependency Rule)

Ничто во внутреннем слое не должно знать о чём-либо во внешнем слое. Имена, типы, классы — ничто, объявленное во внешнем слое, не должно упоминаться во внутреннем.

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

Пример
com.bank.payment
├── domain/                     # Entities
│   ├── model/
│   │   ├── Payment.java
│   │   └── Money.java
│   └── port/
│       ├── in/
│       │   └── CreatePaymentUseCase.java
│       └── out/
│           └── PaymentRepository.java
├── application/                # Use Cases
│   └── CreatePaymentService.java
├── adapter/                    # Interface Adapters
│   ├── in/
│   │   └── web/
│   │       └── PaymentController.java
│   └── out/
│       └── persistence/
│           ├── PaymentJpaRepository.java
│           └── PaymentEntity.java
└── config/                     # Frameworks & Drivers
    └── PaymentBeanConfig.java

Отличие от гексагональной архитектуры

Концептуально Clean Architecture и Hexagonal Architecture очень похожи. Главное отличие — Clean Architecture явно выделяет слой Use Cases и описывает чёткую иерархию из четырёх колец, тогда как гексагональная архитектура фокусируется на портах и адаптерах без строгой внутренней стратификации ядра.

На собеседовании: Интервьюер проверяет, понимаете ли вы Dependency Rule и можете ли объяснить, почему Entity не должен импортировать Spring-аннотации. Частая ошибка — не уметь объяснить отличие Clean Architecture от гексагональной и луковой.