Clean Architecture на примере. Доступно и без кода 

о, Алексей, доброго времени суток🖖🏻

Вам спасибо за интерес!

😂

В принципе, да у UseCase и традиционных Сервисов примерно одна и та же цель -- описывать верхнеуровнейвый бизнес-процесс. Поэтому и реализация у них очень похожа. Едиснтвенная проблема с сервисами -- зачастую они содержат несколько слабосвязных методов. Тоесть вырастает coupling на пустом месте. если я не буду использовать Application слой, то API плагин взаимодействует напрямую с use cases. Вот это не очень понял. Имеете ввиду Application Business Rules слой?

@@stringconcat Да, Application Business Rules слой

Отличные вопросы! Спасибо! 1) нет, так делать нельзя. Ибо в этом случае плагин API будет ссылаться на плагин Data Access. Но! иногда, к примеру для отчетов или еще какой тяжелой аналитики нужно выгрузить несколько тысяч записей из БД, и сделать это быстро. И столько конвертаций может быть делать накладно. Поэтому можно использовать CQRS паттерн. Но я бы в этом случае сделал отдельный модуль, независящий он Clean Architecture, скажем Analytics и в нем бы реализовал работу с хранилищем напрямую. Только стоит помнить, что у этого подхода много минусов в maintainability, главный из которых: как не дать другим разрабочтикам использовать этот шорткат, когда им захочется. Ну и конечно в начале стоит провести tradeoff анализ, чтобы понять что вы получаете и чем жертвуете. 2) Лучше чтобы интерфейсы были, в этом случае вы сможете протестировать контролеры в изоляции от бизнес-логики даже без использования моков, а просто подсунув фейковую имплементацию, ну скажем лямбду.

Если кратко, то каждый микросервис -- это отдельное приложение, каждый микросервис может быть написан на разных языках и иметь разные архитектуры внутри. В том числе и 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 становится слишком умным и через пол годика будет содержать очень внушительную порцию бизнес-логики. А этого бы нам хотелось избежать

Очень хороший вопрос! На все подряд конечно интерфейсы плодить не надо. Я выработал 2 принципа: 1) Интерфейс нужен когда нужно перепрыгнуть из внутреннего круга во внешний. Ну к примеру, если нужно вызвать хранилище из слоя Бизнес логики. Там же без интерфейса не получится, иначе Бизнесу придется зависить от слоя доступа к данным 2) Когда нам нужно несколько реализаций. При этом тесты считаются здесь тоже. К примеру у вас есть какая-то жутко сложная вычислялка процента в бизнес-логике, которая его вычисляет по многим параметрам, включая фазу Луны и индекс Доу-джонса. А вы тестируете, к примеру как вы письмо клиенту составляете автоматически, и вот эту вычислялку задействуете. Но вам абсолютно все равно какое значение она вернет. хоть 0, хоть 100500. И вот в этом случае имеет смысл заменить ее на Fake Implementation. Которая, скажем, всегда будет возвращать 15%

Да, понимаю, огромная проблема донести виденье для разработчиков и установить правила игры :) это ipad air последний и стандартные notes.

Да, дейтсвительно я его не упомянул. Сидел, смотрел на диаграмму и подумал: нет, если я сюда намалюю еще один слой, который связывает все плагины и core вместе, то всех запутаю :) придется еще один ролик выпускать. Спасибо что подсветили!

Если я правильно понял - то это реализация уровня (слоя?) API.

Я так понял, что API это REST, а он не должен зависеть от DAO и прочих плагинов.

@@MrArcsinus А по-моему, REST это как раз плагин

Именно так

Если я правильно понял, то какой нибудь Scheduler? Если так, то он концептуально не сильно отличается от какого-ниубдь контроллера: и тот и другой дергает бизнес логику. Контроллер когда его самомго кто-то подергает. А Шедулер, когда наступит определенно время. таким образом, я бы создал отдельный модуль schedule, который бы и дергал useCase

Рад помочь! :)

Тут еще вопрос в сложности написания тестов, проверки ревью

Достойно отдельного видео! Спасибо за вопрос! Сам мокито то не плох. Как обычно виновато то, как его используют. Проблема в том, что с его помошью можно протестировать вообще все что угодно, замокать любе зависимости, даже если они жестко указаны на какой-то класс. И он НЕ поощряет написание decoupled кода. Это раз. Во-вторых. Есть у вас зависимость, вы ее замокали. А потом стали использовать еще один метод из этой зависимости. И с мокито вы узнаете что нужно все моки дополнить в runtime. А если бы заменили на тестовую заглушку (рукописную), то в compile-time узнали что нужно метод имплментировать.

Слои то есть, просто они не нарисованы концентрическими окружностями. Сверху вниз: app layer, business, data access. То, что app layer окружает бизнес, может означать, что извне можно получить доступ только к app слою. Я так это интерпретировал.