Comments 2
Да ничего оно не дает, кроме сосредоточения "бардака" в одном слое и такой-же кучи зависимостей
Тот же Микрософт дает куда более интересную концепцию: https://learn.microsoft.com/en-us/dotnet/architecture/modern-web-apps-azure/common-web-application-architectures#clean-architecture
Не свою понятно, но с указанием, как разложить по ASP.NET Core и всякие там "заморочки" на уровне IDE
А эта концепция бизнес слоя давно кочует по планете. К примеру, системы класса BPM, ESB также реализуют эту концепцию, что работает на сложном legacy-environment большой конторы, где куда не вступи - все в овно мамонта вступишь :)
Соглашусь, что это не серебряная пуля, и без поддержки качества кода никакая методика работать не будет. Однако, наивный подход "все взаимодействуют со всеми" просто не дает возможности для организации хорошей иерархии взаимодействий, что ведет к помойке сразу со старта разработки, как за качеством не следи.
Методики Microsoft хороши, но они слабо распространены за пределами стека microsoft, и описанную проблему, например, они рекомендуют решать на presentational уровне, что завязывает описание процесса на вью модель и требует впоследствии рефакторинга и разделения "настоящей" вью модели и модели процесса, что собственно и описывается в статье.
Слоистая архитектура приложений: как обеспечить поддерживаемость доменного слоя