Андрей Цветцих — Чистая архитектура на практике

• Братья-разработчики обсуждают преимущества работы на удаленке и рассказывают о своем опыте работы с чистой архитектурой.  

• Они объясняют, что доклад будет полезен для разработчиков с опытом, но также и для тех, кто только начинает изучать эту тему.  

• Братья определяют архитектуру как набор компонентов, публичных контрактов и связей между ними.  

• Они также объясняют, что такое инверсия зависимости и как она работает.  

• Братья обсуждают различные варианты упаковки компонентов по проектам, включая один к одному, когда каждый компонент представляет собой отдельный проект, и два к одному, когда бизнес-логика и интерфейсы для доступа к данным находятся в одном проекте, а реализация - в другом.  

• Братья объясняют, что чистая архитектура состоит из четырех уровней: сущности, юс кейсы, адаптеры, интерфейсы и правила зависимости.  

• В видео обсуждается чистая архитектура, которая состоит из четырех уровней: энтитис, кейси, адаптеры и фреймворки.  

• Энтитис - это бизнес-логика, которая существует без программного обеспечения.  

• Кейси - это сценарии использования приложения, которые не зависят от фреймворка.  

• Адаптеры - это все, что связывает логику с внешним миром, включая веб-контроллеры, внешние сервисы и воркеры.  

• Фреймворки - это все, что не входит в предыдущие уровни, включая базу данных, сканеры, лагеря и тесты.  

• В видео также обсуждается слоистая архитектура, которая состоит из трех уровней: контроллеры, бизнес-логика и доступ к данным.  

• В слоистой архитектуре, в отличие от чистой, направление зависимости сверху вниз.  

• В видео сравниваются чистая и слоистая архитектуры, обсуждаются их сходства и различия.  

• В чистой архитектуре, в отличие от слоистой, интерфейс находится внутри проекта с кейси, а не в модуле доступа к данным.  

• В чистой архитектуре предлагается вынести интерфейс в отдельный проект, чтобы управлять компонентом.  

• В луковой архитектуре есть четыре уровня: модель, сервисы, инфраструктура и тесты.  

• В чистой архитектуре модель и сервисы объединены в один уровень.  

• В луковой архитектуре между уровнями есть зависимости, которые работают по-разному в зависимости от направления.  

• Адаптеры и интерфейсы используются для связи между уровнями.  

• Адаптеры могут быть первичными и вторичными, и правила зависимости работают не всегда.  

• Контроллеры должны быть публичными, но не должны ссылаться на интерфейсы и структуры.  

• Контроллеры могут быть вынесены в отдельный проект для управления зависимостями.  

• Во фреймворках корень композиции является ключевым компонентом, который знает обо всех остальных компонентах.  

• В проекте могут быть добавлены дополнительные компоненты, такие как обработка исключений и сервисы для текущего пользователя.  

• В видео обсуждается чистая архитектура и ее применение в проектах.  

• Рассматриваются различные части проекта, такие как шарит проект, бизнес-логика, интерфейсы для доступа к данным и интерфейсы для доступа к данным.  

• Обсуждается, как поддерживать независимость домена бизнес-логики от инфраструктуры.  

• Рассматривается пример, когда необходимо вызвать сторонний сервис для расчета налога.  

• Предлагается использовать делегат для передачи метода расчета налога.  

• Это позволяет защитить модель и убрать интерфейсы инфраструктуры.  

• Обсуждается, как анемичная модель влияет на архитектуру проекта.  

• Предлагается использовать речь модул, который предполагает больше, чем анемичная модель.  

• Рассматривается подход, в котором запросы делятся на команды, которые меняют состояние.  

• Обсуждается, как это влияет на архитектуру проекта и как это может быть реализовано.  

• Обсуждается, как вынести общую логику в отдельный класс.  

• Рассматриваются примеры, где это может быть полезно, такие как система документооборота.  

• Обсуждаются различные подходы к реализации общей логики и их преимущества и недостатки.  

• В докладе обсуждаются принципы чистой архитектуры, включая принцип версии зависимости и принцип использования специализированных моделей.  

• Упоминается, что создание специализированных моделей может быть более эффективным, чем использование универсальных моделей.  

• В докладе говорится о преимуществах использования чистой архитектуры, включая сокращение времени на создание новых проектов и улучшение коммуникации между разработчиками.  

• Однако, отмечается, что обучение специалистов и создание шаблонов проектов может быть сложным и затратным процессом.  

• В чате обсуждаются вопросы о том, где следует использовать фиширование данных - в слое приложения или в инфраструктуре.  

• Упоминается, что в некоторых случаях, например, в системе документооборота, данные могут быть лучше кэшированы на уровне приложения, в то время как в других случаях, например, в системе бухучета, данные могут быть лучше кэшированы на уровне инфраструктуры.  

• В чате также обсуждаются различия между чистой архитектурой и ее интерпретацией, а также преимущества и недостатки использования разных моделей в зависимости от типа приложения.  

• В архитектуре проекта предлагается использовать слои, где каждый сервис имеет свой интерфейс и реализацию.  

• Это позволяет разделить интерфейсы и реализации, что повышает связанность и снижает зацепление.  

• Автор рассказывает о том, как он убеждал коллег по проекту следовать его принципам архитектуры.  

• Он начал с инициативы снизу, затем заручился поддержкой начальника и показал ему преимущества изменений.  

• Коллеги, которые сначала отнеслись с недоверием, затем стали союзниками в борьбе за изменения.