Presentation (completed)

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): Реализация интерфейсов из Domain слоя (например,
`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. Домен с DDD

ДОМЕН С DDD
18

19. Домен с DDD

ДОМЕН С DDD
19

20. Домен с DDD

ДОМЕН С DDD
20

21. Use case с DDD

USE CASE С DDD
21

22. Use case с DDD

USE CASE С DDD
22

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

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

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

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

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

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

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

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

27. Итоги

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

28. Вопросы

ВОПРОСЫ
28

29. Вопросы

ВОПРОСЫ
1. Какой главный недостаток у традиционного
подхода, когда бизнес-логика тесно связана с
базой данных или фреймворком?
29

30. Вопросы

ВОПРОСЫ
2. Как направ лен поток зависимостей в
Чистой архитектуре?
30

31. Вопросы

ВОПРОСЫ
3. Где в Чистой архитектуре должны находиться
самые стабильные и фундаментальные правила
бизнеса?
31

32. Вопросы

ВОПРОСЫ
4. Слой Сценариев использования (Use Cases)
зависит от базы данных? Почему?
32

33. Вопросы

ВОПРОСЫ
5. Какой принцип SOLID позволяет нам сделать
так, что Сценарий использования зависит от
интерфейса, а не от конкретной реализации
репозитория?
33

34. Вопросы

ВОПРОСЫ
6. Если я хочу добавить новый API-эндпоинт
для управления товарами, в каком слое я создам
контроллер?
34

35. Вопросы

ВОПРОСЫ
7. Представьте, что у вас есть Use Case
"GetUserProfileUseCase". Что он должен
принимать на вход и что возвращать? Должен
ли он возвращать объект модели базы данных?
35

36. Вопросы

ВОПРОСЫ
8. Для чего нужен слой "Адаптеры"?
36

37. Вопросы

ВОПРОСЫ
9. Где в приложении должна происходить "сборка"
всех зависимостей (создание экземпляров Use
Cases, подключения конкретных реализаций
репозиториев, создание контроллеров)?
37

38. Вопросы

ВОПРОСЫ
10. Какой самый главный выигрыш мы получаем
от Чистой архитектуры при написании unitтестов?
38

39. Вопросы

ВОПРОСЫ
11. Верно ли утверждение: "Чистая архитектура
делает начальную разработку быстрее, но
усложняет долгосрочную поддержку"?
39

40. Вопросы

ВОПРОСЫ
12. Когда, возможно, не стоит использовать Чистую
архитектуру?
40