Clean Architecture Desing Pattern

https://8thlight.com/blog/uncle-bob/2012/08/13/the-clean-architecture.html

I have some question about this pattern. The Database is at outter Layer but how would that work in reality? For example if i have a Microservices that just manges this entity:

person{
  id,
  name,
  age
}

And one of the use cases would be manage Persons. Manage Persons is saving / retrieving / .. Persons (=> CRUD operations), but to do this the Usecase needs to talk to a database. But that would be a violation of the Dependency rule

The overriding rule that makes this architecture work is The Dependency Rule. This rule says that source code dependencies can only point inwards.

1. Would this even be a valid use case?
2. how can i access the database if its at the outter layer? (Dependency Iversion?)

If i get a GET /person/{id} Request should my Microservices process it like this?

But using Dependency Inversion would be a Violation of

Nothing in an inner circle can know anything at all about something in an outer circle. In particular, the name of something declared in an outer circle must not be mentioned by the code in an inner circle. That includes, functions, classes. variables, or any other named software entity.

---

Crossing boundaries. At the lower right of the diagram is an example of how we cross the circle boundaries. It shows the Controllers and Presenters communicating with the Use Cases in the next layer. Note the flow of control. It begins in the controller, moves through the use case, and then winds up executing in the presenter. Note also the source code dependencies. Each one of them points inwards towards the use cases.

We usually resolve this apparent contradiction by using the Dependency Inversion Principle. In a language like Java, for example, we would arrange interfaces and inheritance relationships such that the source code dependencies oppose the flow of control at just the right points across the boundary.

For example, consider that the use case needs to call the presenter. However, this call must not be direct because that would violate The Dependency Rule: No name in an outer circle can be mentioned by an inner circle. So we have the use case call an interface (Shown here as Use Case Output Port) in the inner circle, and have the presenter in the outer circle implement it.

The same technique is used to cross all the boundaries in the architectures. We take advantage of dynamic polymorphism to create source code dependencies that oppose the flow of control so that we can conform to The Dependency Rule no matter what direction the flow of control is going in.

Should the Use Case layer Declare an Repository Interface which will be implemented by the DB Package (Frameworks & Drivers Layer)

If the Server recieves a GET /persons/1 Request the PersonRest would create a PersonRepository and would pass this Repository + the ID to the ManagePerson::getPerson Function, getPerson doesnt know PersonRepository but knows the interface it implements so its doesnt violate any rules right? ManagePerson::getPerson would use that Repository to look for the entity and would return a Person Entity to PersonRest::get which would return a Json Objekt to the Client right?

English is sadly not my native language so i hope you guys can let me know if i understood the pattern correct and maybe answer some of my questions.

Ty in advance