Чистая архитектура - Что? Зачем? Почему? (пример на Django)

*Чистая архитектура - Что? Зачем? Почему? (пример на Django)* В этом видео мы обсуждаем *наболевшую проблему спагетти-проектов* — проектов, написанных без какой-либо явно продуманной, качественной архитектуры. *Проблемы "Спагетти-Кода":* Представьте Django-проект, где вся бизнес-логика сосредоточена в моделях, с методами, которые вызывают другие методы в различных моделях и даже в разных приложениях, стучатся по сети, кладут информацию в БД, вызывая сигналы — это настоящий "путь в кроличью нору". В таких проектах бизнес-логика размазывается на несколько файлов, а то и приложений, что делает её сложной для понимания. Я работал над очень крупным проектом (доставка, около 800 тысяч строк кода), где из-за отсутствия архитектуры внедрение новых фич вызывало сильную головную боль, поскольку приходилось путешествовать по всему коду, чтобы понять, куда аккуратно "врезаться" и внести изменения без принесения еще большего хаоса. *Ключевая Идея Чистой Архитектуры:* **Код должен быть простым**. Работа должна приносить удовольствие, и если код непрост, значит, что-то делается не так. Я считаю, что архитектуру, особенно чистую, следует изучать одновременно с началом написания кода. Чистая архитектура (известная по книге Боба Мартина, но основанная на принципах, известных давно, включая SOLID), позволяет нам не портить себе жизнь в долгосрочной перспективе, особенно если проект большой и долгоиграющий. *Основы Чистой Архитектуры:* Ядро Clean Architecture — это **независимость**. Компоненты или слои, особенно слой бизнес-логики (**Use Case**), не должны зависеть ни от кого. Ключевые понятия: *Use Cases (Юзкейсы):* Выделение бизнес-логики в отдельную сущность. *DI (Dependency Injection, внедрение зависимостей):* Позволяет сделать код независимым. *Интерфейсы:* Гарантируют, что два участка кода не зависят друг от друга. *Практический Подход и Пример на Django:* Чтобы начать внедрять чистую архитектуру, даже не охватывая её полностью, необходимо сделать одну важнейшую вещь (краеугольный камень): **выделить бизнес-логику (Use Case) в отдельную структуру/файл**. Это нужно делать с самого начала. Мы разделяем наш серверный код на три части: 1. *Хендлер (View/Ручка):* Принимает запрос, извлекает нужные данные (например, user ID), приводит их к примитивам (или DTO) и передает дальше. 2. *Бизнес-логика (Use Case / Сервисный слой):* Принимает примитивы. *Она не должна знать ничего о фреймворке* (Django), не импортировать модели, сериализаторы, и **не должна лезть в базы данных**. Вся бизнес-логика, расчеты и условия происходят здесь. 3. *Репозиторий:* Специальный код/файл, который занимается доступом к данным — лезет в БД, стучится по сети, работает с Kafka и возвращает данные в Use Case в виде примитивов или специальных структур. *Компромисс для Django:* Поскольку полная реализация чистой архитектуры может снижать скорость разработки, мы обсуждаем компромисс: использование элементов чистой архитектуры точечно. Например, мы можем разрешить Use Case работать с объектами Django (QuerySets), возвращаемыми репозиторием, при условии, что мы обязуемся не использовать в бизнес-логике разрушающие ORM-методы (типа `save()` или `filter()`). *Самое главное:* Use Case не должен зависеть ни от чего. --- Я надеюсь, скоро сделаю еще одно видео, где мы поговорим про инжекцию зависимостей. Вот у меня есть небольшая статья на эту тему что я выкладывал в тг
Кстати подписывайтесь на телеграмм-канал, там у меня посты чаще раза в год)