Введение в Clean Architecture
Clean Architecture (чистая архитектура) – это подход к разработке ПО, который ставит акцент на чистоте и ясности структуры приложения. Он помогает создавать гибкие и легко поддерживаемые системы, которые легко масштабировать и тестировать.
Преимущества Clean Architecture
- Отделение бизнес-логики от деталей реализации
- Улучшение читаемости и понимаемости кода
- Легкость внесения изменений и добавления новых функциональностей
- Улучшение масштабируемости и тестируемости приложения
Пример Clean Architecture
Представим пример применения Clean Architecture на простом приложении для управления списком задач. В таком приложении мы можем выделить следующие уровни:
- Presenter – уровень представления бизнес-логики и интерфейса пользователя
- UseCase – уровень, отвечающий за выполнение бизнес-логики
- Repository – уровень доступа к данным
- Entity – уровень, описывающий бизнес-сущности
Каждый уровень отвечает за свою задачу и не зависит от деталей реализации других уровней. Это позволяет легко изменять и дополнять функциональность приложения, а также позволяет проводить тестирование каждого уровня независимо.
Заключение
Применение Clean Architecture помогает создавать гибкие, чистые и легко поддерживаемые системы. Этот подход позволяет разделить бизнес-логику от деталей реализации, что облегчает работу разработчикам и повышает качество разработанного ПО.
Охапка дров и плов готов 😂, молодец, круто объяснил. Спасибо! 🎉
Супер. Никак не мог структурировать правильно интерфейсы и классы. Спасибо огромное
Спасибо за видео, интересная тема.
Могли бы вы уточнить один момент: если у сегмента с бизнес-логикой в большинстве своём нет интерфейсов, может ли это быть нарушением чистой/гексагональной архитектуры при условии, что предметная область декомпозирована нормально и её реализация соответствует практикам low coupling & high cohesion? Просто складывается впечатление, что чуть ли не основной идеей описанных архитектурных подходов является выделение интерфейсов даже там, где это, казалось бы, смысла не имеет. Например, не понятна польза от интерфейсов для рядовых crud-операций или даже core бизнес логики, если в настоящее время существует единая реализация конкретного процесса, — на мой взгляд, наличие интерфейсов с единой реализацией скорее привносит сложность в проект, к тому же, если у процесса единая реализация, возникает сложность с наименованием интерфейсов и имплементаций, вроде BuisnessProcess и BuisnessProcessImpl.
чувак, ты бы еще на туалетной бумаге или салфетке рисовал. вроде че то по делу говоришь, но подача это просто ппц – какие то кракозябры непонятные, генерирование текста на ходу. тебе настолько пох на твоих подписчиков что ты нормальные слайды поленился сделать?
Да с чего вы все решаете, что отсутствие кода это в плюс!? Наоборот, два три слайда с примерами более информативны чем растекание по древу!
А почему application business layer не является отдельным сервисом?
Просто сперва вы выносили Data access layer в отдельный кружок, а потом App layer как обертку бизнес логики.
Как действовать, есди у меня есть приложение и сайт и у них слегка разная логика? Делать два сервиса: syte и application, которые зависят от контрактов сервиса с бизнес логикой?
Без кода непонятно
А где должен храниться bull process который выполняет таски?
Грубо говоря фоновые службы
сорри, что это за бред? где слои?
вроде как плагины реализуют интерфейсы которые в ядре БЛ, получается что они 'одноразовые' и в другой проект их не вытащить без куска БЛ … ну такоэ
Круть
Да ролик понравился! А теперь попросить хочу снять о разработке через приемочное тестирование (только пример брать не правила переключения сигналов светофора, а что нибуль другое, на ваш выбор). Так называемое Atdd. В каком случае нужен приемочный тест а в каком переходим к юнит тесту, разобрать разницу, Спасибо.
Охуенно! То, что искал! Спасибо огромное!
Дружище…почитай заново схему Дади Боба…и посмотри внимательно где находятся UseCases
Ничего не поняла,что хотел сказать(((
По дяде Бобу должно быть несколько конц.кругов. А где они здесь? Здесь все в куче по центру. почему и зачем не понятно((
Пуши на голубях и кофейная гуща вместо бюро кредитных историй это хорошооо😂
Рад новому отличному каналу!
Здравствуйте! Расскажите пожалуйста как совмещать Clean Architecture с Microservice Architecture, если это возможно. Каждый микросервис отдельно разрабатывать как Clean Architecture? Или например Core Business Rules вынести в отдельную сборку, которая будет использоваться всеми микросервисами? А Application Business Rules делать для каждого микросепрвиса свои.
Лайк поставлю, потом посмотрю , о чем то умном говорят
5.46: А что не так с mockito?! 😀
Интересная серия роликов про архитектуру. Спасибо, с меня подписка.