insight 
In 2017 Uncle Bob wrote a great book about clean architecture. It explains the principles of a good software architecture. The book contains lots of information about the SOLID principles, about boundaries in the application, about screaming architecture, and so forth.rnWhat’s great about the book, is that it isn’t dogmatic. It doesn’t have code samples explaining how to implement a use case or a controller. However, at some point you need to start coding. This leads to the question: What could a clean architecture look like?rnIn this article I’ll explain my take on clean architecture.
A cab dispatching application contains several other domain concepts too. Like a cab, a cab driver, and a passenger for example. There’s a difference between these objects. Either their state changes, or they are immutable. A location, for example, is immutable. A cab, on the other hand, is not. It has an increasing mileage. And it is either taken or not. As a result, a cab entity is probably not a struct, but a class, and it might look like this:
3.) Controllers
The use cases and the entities are the core of the application. By invoking one, or a sequence of use cases, an application can achieve a business goal. There are several “things” that can do this. In case of an event-driven application, a command handler will typically invoke the use-cases. In my case, I’m building a REST API, and the consumer of the API can invoke the use-cases directly. A simple controller will look like this:
Or, in a more complex scenario:
Note that I’m not using dependency injection on the constructor to inject the use-cases into the controller. I’m injecting directly into the method instead, because every controller method will probably use another use-case.
Using this DBContext: