…with fluent validation and automapping…
Today I just want to share a basic skeleton web api written in .net core. This is a kind of basic set up which works fine for microservices as well as some bigger ones. So I am a very big fan of not only horizontal layering ( see post Horizontal and Vertical Layers in Software Development). The example also shows how an application layer validation could e applied and how to easily map the items through the layers. So may be this helps the one or the other…
First the link to the source: layered-net-core-app
So this skeleton app shows how an application could be split into vertical layers. This has multiple advantages (again see Horizontal and Vertical Layers in Software Development). Furthermore it shows with one example the flow of the data and connections from top (controller/application layer) to bottom (data layer). The data layer is only pseudo code and does not persist stuff, to focus on the layering and communication stuff.
The application has three layers:
- Application Layer
- Business Layer
- Data Layer
…and several projects:
- WebApi (Contains startup, adding middleware, setups, controller routings, forming the output and at least hosting the application)
- WebApi.Configuration (DI bootstrapping / connecting the layers together)
- WebApi.Common (Common stuff for the web api)
- Application (The implementation of the application layer)
- Application.Contract (The access to the application layer from outside the application layer)
- Business (The implementation of the business layer)
- Business.Contract (The access to the business layer from outside the business layer)
- DataLayer (The implementation of the data layer)
- DataLayer.Contract (The access to the data layer from outside the data layer)
The application layer is used here in this example by the web api project (Controllers). But the Controllers has only access to the application layer contracts. This allows us to avoid unwanted direct connection to use the implementation directly or to access business entities which knows the application layer implementation, but should not possible to expose by the api to the “outer world”. The application layer implementation knows only about the business layer contracts to communicate with it.
What this layer will does depends on the call and the needs for it. But from my perspective it is responsible for providing services for getting data from business/domain side and/or triggers domain/business logic. Furthermore it orchestrate all this needed calls to business logic and for example third party services to get/set the wanted result.
The business layer knows only about the data layers contracts. The business lay exposes only interfaces to use the layer and the business entities.
This layer should contain all the business/domain logic. All business relevant calculations and manipulations should occur here. No manipulation of business entities should be done outside of this layer.
The data layer knows only about the database or storage where all the data is persisted. The contracts from the data layer should only be used from the business logic to make sure that persisting data follows the rules inside the business layer. It is the connection to database and or storage. If provides repositories to store and get items from the database/storge.
This splitting is for the most services to much, but it demonstrates very well how the layer can securely communicate to each other. This pattern fits best for situations where no object relation mapper is used, because in entity framework the business entities are the tables in the data layer. So this layer is mostly a little overdone.
Personal I think a layering in microservices for an application layer and domain layer (where all the domain logic and data storage is handled ) is the best compromise to securely work with domain logic and have not total overhead of bubbling through thousands of layers. But this depends like every time on the needs of the application.