What are clean architecture use cases in MVC?

Question

Software design

I decided to read a little about clean architecture in the view of Robert Martin. I did not understand the above division into layers regarding the architecture of the web application a little. With entities, controllers, frameworks, in general, it’s probably understandable. However, a question arose regarding the red layer - use cases. As far as I understand, it contains the main business logic of the application. I understand correctly that in the classic MVC, the red and green layers are not separated, because logic is written in controllers (or models, it doesn't matter). Or does the green layer represent only routes, and the red one - controllers, models? Thanks in advance.

Add. question

Also, I didn’t really understand why Robert selects the Database in the topmost layer. If, judging by the hint, we take into account that the blue layer is a framework, everything is logical, because it does not depend on anything and manages all underlying layers, but this cannot be said about the database, because. underlying layers will interact with it anyway, violating the dependency rule. Is not it?

Answer 1

However, there was a question regarding the red layer - use cases

Use-cases are how the user interacts with your application. (written by Application Business Rules)
Entities - data and rules for working with them (written by Entreprise Business Rules)

I understand correctly that in the classic MVC, the red and green layers are not separated, because logic is written in controllers (or models, it doesn't matter). Or does the green layer represent only routes, and the red one - controllers, models?

In controllers, only logic is written that glues the model and the view. Ideally controllers should be single line

Also, I didn’t really understand why Robert selects the Database in the topmost layer.

At the very core are entities that are not required to be converted 1-to-1 in the database model.
The database layer itself is External Interfaces, just like the framework.

because underlying layers will interact with it anyway, violating the dependency rule. Is not it?

That's the point of Clean Architecture, that no one depends on the database.
There must be some kind of abstraction that allows you to receive data, and in a separate module there will already be an implementation on top of the database.
This is also mentioned in the same book with the corresponding pictures.