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