Что представляю из себя use cases из clean architecture в MVC?

Question

[midia21]

Решил немного почитать о чистой архитектуре в представлении Роберта Мартина. Немного не понял приведенное выше разделение на слои относительно архитектуры веб приложения. С сущностями, контроллерами, фрэймворками в общем то, наверное, понятно. Однако возник вопрос относительно красного слоя - use cases. На сколько я понял в нем зашита основная бизнес логика приложения. Я правильно понимаю что в классическом MVC красный и зеленый слои не разделяются, т.к. логика пишется в контроллерах (или моделях, неважно). Или же зеленый слой представляет из себя только роуты, а красный - контроллеры, модели? Заранее спасибо.

Доп. вопрос

Также не особо понял почему Робер выделяет в самый верхний слой Базу данных. Если судя по подсказке учесть, что синий слой - фрэймворк - все логично, т.к. он ни от чего не зависит и управляет всеми нижележащими слоями, однако о базе данных такое нельзя сказать, т.к. нижележащие слои полюбому будут с ней взаимодействовать, нарушая правило зависимостей. Разве не так?

Answer 1

[Василий Банников]

Однако возник вопрос относительно красного слоя - use cases

Use-cases это то, как пользователь взаимодействует с вашим приложением. (написано Application Business Rules)

Entities - данные и правила работы с ними (написано Entreprise Business Rules)

Я правильно понимаю что в классическом MVC красный и зеленый слои не разделяются, т.к. логика пишется в контроллерах (или моделях, неважно). Или же зеленый слой представляет из себя только роуты, а красный - контроллеры, модели?

В контроллерах пишется только логика, которая склеивает модель и вьюшку. В идеальном случае контроллеры должны быть однострочными

Также не особо понял почему Робер выделяет в самый верхний слой Базу данных.

В самом ядре находятся сущности, которые не обязаны 1-в-1 преобразовываться в модели БД.
Сам слой с базой данных - это External Interfaces, как и фреймворк.

т.к. нижележащие слои полюбому будут с ней взаимодействовать, нарушая правило зависимостей. Разве не так?

В том и смысл Clean Architecture, что никто от БД не зависит.
Должна быть какая-нибудь абстракция, которая позволяет получать данные, а в отдельном модуле уже будет реализация поверх БД.
Об этом в той самой книжке тоже говорится с соответствующими картинками.