Ничего не поняла,что хотел сказать((( По дяде Бобу должно быть несколько конц.кругов. А где они здесь? Здесь все в куче по центру. почему и зачем не понятно((
@ФилиппБондарев Жыл бұрын
Да с чего вы все решаете, что отсутствие кода это в плюс!? Наоборот, два три слайда с примерами более информативны чем растекание по древу!
@batazor9 ай бұрын
Тут еще вопрос в сложности написания тестов, проверки ревью
@millkiway36824 күн бұрын
Потому что архитектура системы это метаинформация и с кодом не связана - а реализовать ее можно различными способами. Поэтому для понимания архитектурных паттернов системы код ни только не нужен, но и вреден.
@t0digital Жыл бұрын
Пуши на голубях и кофейная гуща вместо бюро кредитных историй это хорошооо😂 Рад новому отличному каналу!
@knowledgedose1956 Жыл бұрын
о, Алексей, доброго времени суток🖖🏻
@momentgi9 ай бұрын
Супер. Никак не мог структурировать правильно интерфейсы и классы. Спасибо огромное
@andreypozin8048 Жыл бұрын
Дружище...почитай заново схему Дади Боба...и посмотри внимательно где находятся UseCases
@mexvision-35563 ай бұрын
дружище, включай свою голову и пиши код в зависимости от задачи. Хочешь, создай Domain Use Cases, а хочешь - Application Use Cases. Тебе дали концепцию - а не руководитель. Включай свой котелок и модифицируй под свои нужды. В данном видео, показана база, задумка. Или ты хотел за 10 минут дохуя архитектором стать? =)
@channel-yg2xc10 ай бұрын
Спасибо за видео, интересная тема. Могли бы вы уточнить один момент: если у сегмента с бизнес-логикой в большинстве своём нет интерфейсов, может ли это быть нарушением чистой/гексагональной архитектуры при условии, что предметная область декомпозирована нормально и её реализация соответствует практикам low coupling & high cohesion? Просто складывается впечатление, что чуть ли не основной идеей описанных архитектурных подходов является выделение интерфейсов даже там, где это, казалось бы, смысла не имеет. Например, не понятна польза от интерфейсов для рядовых crud-операций или даже core бизнес логики, если в настоящее время существует единая реализация конкретного процесса, - на мой взгляд, наличие интерфейсов с единой реализацией скорее привносит сложность в проект, к тому же, если у процесса единая реализация, возникает сложность с наименованием интерфейсов и имплементаций, вроде BuisnessProcess и BuisnessProcessImpl.
@stringconcat10 ай бұрын
Очень хороший вопрос! На все подряд конечно интерфейсы плодить не надо. Я выработал 2 принципа: 1) Интерфейс нужен когда нужно перепрыгнуть из внутреннего круга во внешний. Ну к примеру, если нужно вызвать хранилище из слоя Бизнес логики. Там же без интерфейса не получится, иначе Бизнесу придется зависить от слоя доступа к данным 2) Когда нам нужно несколько реализаций. При этом тесты считаются здесь тоже. К примеру у вас есть какая-то жутко сложная вычислялка процента в бизнес-логике, которая его вычисляет по многим параметрам, включая фазу Луны и индекс Доу-джонса. А вы тестируете, к примеру как вы письмо клиенту составляете автоматически, и вот эту вычислялку задействуете. Но вам абсолютно все равно какое значение она вернет. хоть 0, хоть 100500. И вот в этом случае имеет смысл заменить ее на Fake Implementation. Которая, скажем, всегда будет возвращать 15%
@serhiiboiko8957 Жыл бұрын
Здравствуйте! Расскажите пожалуйста как совмещать Clean Architecture с Microservice Architecture, если это возможно. Каждый микросервис отдельно разрабатывать как Clean Architecture? Или например Core Business Rules вынести в отдельную сборку, которая будет использоваться всеми микросервисами? А Application Business Rules делать для каждого микросепрвиса свои.
@stringconcat Жыл бұрын
Если кратко, то каждый микросервис -- это отдельное приложение, каждый микросервис может быть написан на разных языках и иметь разные архитектуры внутри. В том числе и Clean Architecture. На мой взгляд если вы переиспользуете business rules, то скорее всего вы разбили приложение на микросервисы не оптимально, и они тесно связаны (coupled) друг с другом. Лучше всего микросервисы разбивать по bounded Context. Один микросервис -- один Context. А один контекст -- один набор бизнес правил. Если вы смотрите на микросеривисы и видите что лучше бы вынести ядро, то я бы порекомендовал подумать над тем, а не слить ли эти микросервисы в один. Я допускаю что можно сделать библиотеку, куда вынести какие-то совсем общие типы, к примеру Count, Money и пр. Но Это все же не ядро. Спасибо за вопрос. Постараюсь записать видео на эту тему!
@serhiiboiko8957 Жыл бұрын
@@stringconcat спасибо за Ваш ответ. Если можно, то хочу ещё спросить. В чистой архитектуре есть инфраструктурный слой. На сколько я понял он отвечает за работу с базами данных. С Redis. С брокерами сообщений. В Вашей схеме это Right Side. В микросервисной архитектуре есть гейтвей, который не работает напрямую с базами данных. Но он ведь тоже может быть разработан на основе чистой архитектуры. Будет ли в нём присутствовать инфраструктурный слой? Думаю что да, но отвечать он уже будет за работу с микросервисами, а не с базами данных. Правильно ли я понимаю? То же самое относится к клиентским приложениям, которые взаимодействуют со шлюзом. Инфраструктурный слой этих приложений будет отвечать за работу со шлюзом. Правильно?
@stringconcat Жыл бұрын
@@serhiiboiko8957 Да, вы все правильно говорите, в случае gateway (или BFF) правые плагины будут, скажем REST клиентами к вашим микросервисам. Но, мне кажется что если BFF требует чистую архитектуру, то возможно в него попало слишком много бизнес правил. А это зачастую считается антипаттерном.
@serhiiboiko8957 Жыл бұрын
@@stringconcat в моём понимании BFF является интерфейсом между клиентом и разными бизнес логиками, которые реализованы на разных микросервисах и могут предоставлять информацию в рамках своей ответственности, но BFF может консолидировать эту информацию и отдавать клиенту одним пакетом. Т.е. бизнес логика BFF сводится к консолидации полученной от микросервисов информации. Получается, что для такого случая лучне использовать Layered Architecture? Я правильно понимаю? А для клиентского приложения? Если это толстый клиент с какой-то своей бизнес логикой (например какие-то расчёты, которые выгоднее делать на клиенте чам гонять по сетке), то наверное лучше использовать Clean или Hexagonal архитектуру. А если это веб приложение и вся бизнес логика на серверах, то наверное тоже лучше использовать Layered Architecture? Я правильно понимаю? Или для таких случаев есть ещё какая-то архитектура?
@stringconcat Жыл бұрын
@@serhiiboiko8957 я ба наверное вот как определил необходимость использование CA или Hexagonal: Если в приложении есть бизнес-логика (вот прям доменная сложность), то лучше использовать CA или Hexagonal. Теперь про BFF. я встречал 2 варианта 1. Нам нужно запросить данные из микросервиса 1, и из микросервиса 2. Скомпоновать их и отдать клиенту. В этом случае я бы не разделял даже на слои, одни и те же DTO используются чтобы получить ответ от микросервисов и отдать его клиенту. Или даже map'ы, чтобы при добавлении нового поля в микросервис не сильно заморачиваться с BFF. 2. Появляются зачатки логики: Мне нужно запросить данные из микросервиса 1, и если данные содержат X, то запросить из микросервиса 2, а если Y, то из микросервиса 3. А если содержат Z, то вообще спрятать это поле. И это уже похоже на вполне себе бизнес-логику, и в этом случае да, я бы использовал CA или Hexagonal. Но на мой взгляд это запах того, что наш BFF становится слишком умным и через пол годика будет содержать очень внушительную порцию бизнес-логики. А этого бы нам хотелось избежать
@arvpro8970 Жыл бұрын
А где должен храниться bull process который выполняет таски? Грубо говоря фоновые службы
@stringconcat Жыл бұрын
Если я правильно понял, то какой нибудь Scheduler? Если так, то он концептуально не сильно отличается от какого-ниубдь контроллера: и тот и другой дергает бизнес логику. Контроллер когда его самомго кто-то подергает. А Шедулер, когда наступит определенно время. таким образом, я бы создал отдельный модуль schedule, который бы и дергал useCase
@bubbletubbe Жыл бұрын
вроде как плагины реализуют интерфейсы которые в ядре БЛ, получается что они 'одноразовые' и в другой проект их не вытащить без куска БЛ ... ну такоэ
@meteysh9 ай бұрын
Охапка дров и плов готов 😂, молодец, круто объяснил. Спасибо! 🎉
@Lapteuh Жыл бұрын
Спасибо большое! У меня пара вопросов: 1) Что делать с транзитивными зависимостями? Можно ли минуя app biz rules импортировать интерфейсы? У сложилось мнение, что так делать нельзя. Хотелось бы ваше мнение услышать. 2) Нужны ли интерфейсы в use case, если можно сразу данные передать, а вернуть события?
@stringconcat Жыл бұрын
Отличные вопросы! Спасибо! 1) нет, так делать нельзя. Ибо в этом случае плагин API будет ссылаться на плагин Data Access. Но! иногда, к примеру для отчетов или еще какой тяжелой аналитики нужно выгрузить несколько тысяч записей из БД, и сделать это быстро. И столько конвертаций может быть делать накладно. Поэтому можно использовать CQRS паттерн. Но я бы в этом случае сделал отдельный модуль, независящий он Clean Architecture, скажем Analytics и в нем бы реализовал работу с хранилищем напрямую. Только стоит помнить, что у этого подхода много минусов в maintainability, главный из которых: как не дать другим разрабочтикам использовать этот шорткат, когда им захочется. Ну и конечно в начале стоит провести tradeoff анализ, чтобы понять что вы получаете и чем жертвуете. 2) Лучше чтобы интерфейсы были, в этом случае вы сможете протестировать контролеры в изоляции от бизнес-логики даже без использования моков, а просто подсунув фейковую имплементацию, ну скажем лямбду.
@nill-tu3ey6 ай бұрын
Охуенно! То, что искал! Спасибо огромное!. "Миша, Вве херня, давай по новой" (с).
@stringconcat5 ай бұрын
Спасибо, Рад что помог!
@МихаилХейфец-ю8б Жыл бұрын
А почему application business layer не является отдельным сервисом? Просто сперва вы выносили Data access layer в отдельный кружок, а потом App layer как обертку бизнес логики. Как действовать, есди у меня есть приложение и сайт и у них слегка разная логика? Делать два сервиса: syte и application, которые зависят от контрактов сервиса с бизнес логикой?
@mexvision-35563 ай бұрын
Логика которая меняется от сайта к приложению должна быть вынесена в Application. Это уже не является бизнес логикой. Представьте себе что слой Application - это некий посредник между пользователем и ядром вашего приложения. Application и Infrastructure могут меняться. В инфраструктурном слое как правило содержатся реализации тех самых интерфейсов, а слой приложения уже решает какую реализацию в каком юзкейсе использовать. Как отвалидировать данные, какие ответы вернуть. Данная логика может меняться спокойно, но логика домена всегда одна и та же.
@paulkasler2173 Жыл бұрын
Лайк поставлю, потом посмотрю , о чем то умном говорят
@burialstance Жыл бұрын
😂
@vladchukhil27046 күн бұрын
посмотрел?
@paulkasler21736 күн бұрын
@@vladchukhil2704 вот спасибо напомнил, сейчас посмотрю
@aleksandrkokin6065 Жыл бұрын
Поясните пожалуйста, если я не буду использовать Application слой, то API плагин взаимодействует напрямую с use cases? И хотелось бы поподробнее узнать про use кейсы, можно ли их называть сервисами?
@stringconcat Жыл бұрын
В принципе, да у UseCase и традиционных Сервисов примерно одна и та же цель -- описывать верхнеуровнейвый бизнес-процесс. Поэтому и реализация у них очень похожа. Едиснтвенная проблема с сервисами -- зачастую они содержат несколько слабосвязных методов. Тоесть вырастает coupling на пустом месте. если я не буду использовать Application слой, то API плагин взаимодействует напрямую с use cases. Вот это не очень понял. Имеете ввиду Application Business Rules слой?
@alexkokin-p9m Жыл бұрын
@@stringconcat Да, Application Business Rules слой
@ivan_xalie Жыл бұрын
5.46: А что не так с mockito?! :D
@stringconcat Жыл бұрын
Достойно отдельного видео! Спасибо за вопрос! Сам мокито то не плох. Как обычно виновато то, как его используют. Проблема в том, что с его помошью можно протестировать вообще все что угодно, замокать любе зависимости, даже если они жестко указаны на какой-то класс. И он НЕ поощряет написание decoupled кода. Это раз. Во-вторых. Есть у вас зависимость, вы ее замокали. А потом стали использовать еще один метод из этой зависимости. И с мокито вы узнаете что нужно все моки дополнить в runtime. А если бы заменили на тестовую заглушку (рукописную), то в compile-time узнали что нужно метод имплментировать.
@ПростоЁж-щ3ъ Жыл бұрын
Интересная серия роликов про архитектуру. Спасибо, с меня подписка.
@stringconcat Жыл бұрын
Вам спасибо за интерес!
@StanislavPozdnyakov5 ай бұрын
хотелось бы ещё примеров с Application Business Rules. Не до конца понял разницу с Core Business Rules.
@herbslife-miscusi Жыл бұрын
Спасибо! теперь лучше понимаю. Сам интуитивно продвигал\стоил по тем же принципам) но без четкой понятийной базы и защищать эти решения было сложно. btw, а что за программа на планшете? что за планшет?)
@stringconcat Жыл бұрын
Да, понимаю, огромная проблема донести виденье для разработчиков и установить правила игры :) это ipad air последний и стандартные notes.
@KostiaKubik2 ай бұрын
видео хорошее но оно не совсем о clean architecture оно именно о domain уровне (уровне бизнес логики) так как я раньше уже интересовался чистой архитектурой то понял но для человека который только начал изучать данную тему второй круг очень мало вероятно что поймет в чем его суть и зачем он нужен
@MrArcsinus Жыл бұрын
По-моему, пропущен еще один важный компонент приложения: тот, в котором создадутся все инстансы юзкейсов, инстансы реализаций интерфейсов и прочие конфиги безопасности. Там где-то будет public static void main, если это Spring boot , например. И ему придется зависит от всех модулей
@stringconcat Жыл бұрын
Да, дейтсвительно я его не упомянул. Сидел, смотрел на диаграмму и подумал: нет, если я сюда намалюю еще один слой, который связывает все плагины и core вместе, то всех запутаю :) придется еще один ролик выпускать. Спасибо что подсветили!
@ivan_xalie Жыл бұрын
Если я правильно понял - то это реализация уровня (слоя?) API.
@MrArcsinus Жыл бұрын
Я так понял, что API это REST, а он не должен зависеть от DAO и прочих плагинов.
@ivan_xalie Жыл бұрын
@@MrArcsinus А по-моему, REST это как раз плагин
@MrArcsinus Жыл бұрын
Именно так
@sergeyplotnikov4303 Жыл бұрын
Без кода непонятно
@KJLUM.15 ай бұрын
Чувак спасибо за контент, все круто и подробно обьяснил но беда со звуком, слишком тихо, приходится прям прислушиваться
@stringconcat5 ай бұрын
Спасибо! В следующий раз исправим!
@alexkokin-p9m Жыл бұрын
это превосходно, спасибо
@evgenasd8892 Жыл бұрын
Да ролик понравился! А теперь попросить хочу снять о разработке через приемочное тестирование (только пример брать не правила переключения сигналов светофора, а что нибуль другое, на ваш выбор). Так называемое Atdd. В каком случае нужен приемочный тест а в каком переходим к юнит тесту, разобрать разницу, Спасибо.
@yessimovaindira80163 ай бұрын
На доске гораздо быстрее и нагляднее было бы
@mewforest Жыл бұрын
Охуенно! То, что искал! Спасибо огромное!
@stringconcat Жыл бұрын
Рад помочь! :)
@masserrackheim535811 ай бұрын
чувак, ты бы еще на туалетной бумаге или салфетке рисовал. вроде че то по делу говоришь, но подача это просто ппц - какие то кракозябры непонятные, генерирование текста на ходу. тебе настолько пох на твоих подписчиков что ты нормальные слайды поленился сделать?
@jellyfish6265 Жыл бұрын
сорри, что это за бред? где слои?
@МихаилХейфец-ю8б Жыл бұрын
Слои то есть, просто они не нарисованы концентрическими окружностями. Сверху вниз: app layer, business, data access. То, что app layer окружает бизнес, может означать, что извне можно получить доступ только к app слою. Я так это интерпретировал.
@mexvision-35563 ай бұрын
@@МихаилХейфец-ю8б ну это обычная луковая архитектура, все верно. Есть ли разница в каком порядке слои рисовать? Концептуально данный подход верный. Вы же не получаете доступ из-нутри, как правило запросы приходят из вне. Потому в самом центре бизнес логика, к ней доступ только через верхний слой.
@НажмутдинБадрутдинов Жыл бұрын
Круть
@veryvery84306 ай бұрын
а нахер тогда нам обяснение про код без кода
@bunchatests2 ай бұрын
Ничего непонятно. Плохая инфографика. Лучше бы нормальную схему начертил, чем каракули на айпаде. Спасибо за старания, но видео откровенно не очень получилось.