Presentation (completed) (1)

1. Чистая архитектура

ЧИСТАЯ АРХИТЕКТУРА

2. содержание

СОДЕРЖАНИЕ
1. Проблема: Почему стареет ПО?
2. Введение в Чистую архитектуру: Основная идея
3. Ключевые принципы: Зависимости и бизнеслогика
4. Слои архитектуры: Детальный разбор "луковичной"
модели
5. Практическая реализация: Как это выглядит в коде
6. Преимущества и сложности
7. Итоги
2

3. Проблема: Хрупкость и связность традиционного ПО

ПРОБЛЕМА: ХРУПКОСТЬ И
СВЯЗНОСТЬ ТРАДИЦИОННОГО ПО
Основные проблемы
• Жесткая связность (High Coupling): Модули тесно переплетены. Изменение в
одном ломает другое
• Низкое зацепление (Low Cohesion): Логика размазана по всему приложению
• Зависимость от деталей: Бизнес-логика зависит от баз данных, фреймворков
3

4. Что такое Чистая архитектура?

ЧТО ТАКОЕ ЧИСТАЯ АРХИТЕКТУРА?
Архитектурный подход, который делает систему:
• Независимой от фреймворков
• Тестируемой
• Независимой от ЛЮБЫХ внешний зависимостей
Главная цель: Разделить ответственность и управлять зависимостями.
4

5. Ключевые принципы: Dependency Rule

КЛЮЧЕВЫЕ ПРИНЦИПЫ:
DEPENDENCY RULE
Правило зависимостей: Поток зависимостей может указывать только внутрь.
• Ничто во внутреннем круге не может знать что-либо о внешнем круге.
• Внутренние круги содержат политики (политики — это бизнес-логика).
• Внешние круги содержат механизмы (базы данных, фреймворки, API).
5

6. Еще два ключевых принципа

ЕЩЕ ДВА КЛЮЧЕВЫХ ПРИНЦИПА
6

7. Слои чистой архитектуры

СЛОИ ЧИСТОЙ АРХИТЕКТУРЫ
7

8. Проблема: Сложность предметной области

ПРОБЛЕМА: СЛОЖНОСТЬ ПРЕДМЕТНОЙ
ОБЛАСТИ
• Сложность не в технологиях, а в домене (предметной области).
• Неправильная модель предметной области = неадекватное ПО.
• Разрыв между экспертами предметной области и разработчиками.
Результат:
• ПО не решает реальные бизнес-проблемы.
• Постоянные переделки и "костыли".
8

9. Что такое Domain-Driven Design (DDD)?

ЧТО ТАКОЕ DOMAIN-DRIVEN DESIGN
(DDD)?
Подход к разработке ПО, который фокусируется на сложной
предметной области (domain).
Основная цель: Создать программную модель, которая точно отражает
domain.
Ключевые идеи:
• Сотрудничество с экспертами предметной области (не ITспециалисты)
• Единый язык (Ubiquitous Language): Один общий язык для
разработчиков, экспертов и кода
• Разбиение большой модели на управляемые части (Модули, Bounded
Context)
9

10. Ключевые строительные блоки DDD?

КЛЮЧЕВЫЕ СТРОИТЕЛЬНЫЕ БЛОКИ
DDD?
Сущность (Entity): Объект, уникально идентифицируемый (например,
по ID). (User, Order, Account).
Объект-Значение (Value Object): Объект, не имеющий идентификатора,
описывающий характеристику. Неизменяемый. (Money, Address, Color).
Агрегат (Aggregate): Кластер из связанных объектов (Сущностей и
Значений), который рассматривается как единое целое. Имеет корень
(Aggregate Root).
Сервис домена (Domain Service): Операция, которая не уместна внутри
Агрегата или Сущности (сложная бизнес-логика, затрагивающая
несколько Агрегатов).
Репозиторий (Repository): Абстракция для хранения и извлечения
Агрегатов (обычно по корню).
Фабрика (Factory): Создание сложных объектов или Агрегатов.
10

11. Синергия: DDD + Clean Architecture

СИНЕРГИЯ: DDD + CLEAN ARCHITECTURE
11

12. Домен (Domain Layer)

ДОМЕН (DOMAIN LAYER)
Что это? Богатая модель предметной области, построенная по принципам DDD.
Содержит:
• Сущности (Entities) и Агрегаты (Aggregates) с инкапсулированной логикой
• Объекты-Значения (Value Objects)
• Сервисы домена (Domain Services)
• Интерфейсы Репозиториев (Repository Interfaces) (DIP!)
Пример Агрегата Order:
• Корень: Order (Сущность).
• Внутри: OrderLine (Value Object), Address (Value Object).
• Методы: `order.addItem(...)`, `order.calculateTotal()`, `order.cancel()`.
Не содержит: Реализаций репозиториев, внешних сервисов.
12

13. Сценарии использования (Use Cases / Application Layer)

СЦЕНАРИИ ИСПОЛЬЗОВАНИЯ (USE
CASES / APPLICATION LAYER)
Что это? Orchestration-слой, который координирует задачи приложения.
Аналог: Application Service в DDD.
Пример: CreateOrderUseCase, CancelOrderUseCase.
Содержит: Логику координации, но НЕ бизнес-правила домена.
• Вызывает методы Агрегатов домена.
• Использует Репозитории для загрузки/сохранения Агрегатов.
• Может вызывать Сервисы домена.
• Управляет транзакциями (на уровне приложения).
Зависит от: Доменного слоя (внутрь).
13

14. Адаптеры интерфейсов (Interface Adapters)

АДАПТЕРЫ ИНТЕРФЕЙСОВ (INTERFACE
ADAPTERS)
Что это? Мост между нашим внутренним миром и внешним.
Состоит из:
• Контроллеры (Controllers): Принимают HTTP-запросы, вызывают Use Case,
возвращают HTTP-ответы.
• Презентеры (Presenters):** Подготавливают данные для отображения
(например, в JSON для API).
• Шлюзы (Gateways): Реализация интерфейсов из Use Case слоя (например,
`UserRepositoryImpl`).
• DTO (Data Transfer Objects): Объекты для передачи данных через границы
слоев.
14

15. Внешняя инфраструктура (Frameworks & Drivers)

ВНЕШНЯЯ ИНФРАСТРУКТУРА
(FRAMEWORKS & DRIVERS)
Что это? Все инструменты и фреймворки, которые мы используем.
Примеры:
• Базы данных (MySQL, PostgreSQL, MongoDB).
• Веб-фреймворки (Spring, Express.js, Django).
• Внешние API (Email-сервисы, платежные шлюзы).
• UI (Web, Mobile, Desktop).
• Брокеры сообщений (RabbitMQ, Kafka).
Этот слой «подключается» к нашему ядру через Адаптеры.
15

16. Собираем все вместе: Схема потока данных

СОБИРАЕМ ВСЕ ВМЕСТЕ: СХЕМА ПОТОКА
ДАННЫХ
16

17. Домен с DDD

ДОМЕН С DDD
17

18. Use case с DDD

USE CASE С DDD
18

19. Уровень адаптеров

УРОВЕНЬ АДАПТЕРОВ
19

20. Уровень Фреймворка (Настройка зависимостей)

УРОВЕНЬ ФРЕЙМВОРКА (НАСТРОЙКА
ЗАВИСИМОСТЕЙ)
20

21. Преимущества архитектуры

ПРЕИМУЩЕСТВА АРХИТЕКТУРЫ
• Независимость от фреймворков: Легко обновлять или менять.
• Тестируемость: Ядро можно тестировать unit-тестами без базы данных
и веб-сервера. (`RegisterUserUseCase` можно протестировать с
`FakeUserRepository`).
• Независимость от UI: Можно сменить веб-интерфейс на CLI без
изменения бизнес-логики.
• Долгосрочная поддерживаемость: Код организован, понятен и
предсказуем.
• Разделение ответственности: Каждый разработчик понимает, куда
писать код.
21

22. Сложности и когда (не) использовать

СЛОЖНОСТИ И КОГДА (НЕ)
ИСПОЛЬЗОВАТЬ
Сложности:
• Бойлерплейт: Больше классов, больше файлов.
• Кривая обучения: Требует дисциплины и понимания принципов.
• Over-engineering для простых CRUD-приложений.
Когда использовать?
• Сложные доменные модели (Core Domain в DDD).
• Долгосрочные проекты.
• Когда важна предсказуемость и тестируемость.
Когда можно не использовать?
• Простые прототипы, MVP.
• Очень маленькие приложения без сложной логики.
22

23. Итоги

ИТОГИ
Ключевая мысль: Сначала думайте о бизнесе, потом о технологиях.
• Управляйте зависимостями: они должны быть направлены внутрь, к
бизнес-правилам.
• Изолируйте ядро (Entities, Use Cases) от деталей (БД, Фреймворки).
• Используйте интерфейсы и DIP для разрешения зависимостей на
уровне кода.
• Это требует дисциплины, но делает систему гибкой, тестируемой и
долговечной.
23