Infrastructur-ing

We started a new project, from scratch.

As you should already know, it’s quite unusual and great to have the opportunity of writing a project from scratch.
Therefore, we grabbed this with both hands. 

The most important thing with new projects, beside POC unknown territories (post about this in a near future), is to have a good infrastructure.

After a month (+-) of designing the whole system, we were ready to start building the infrastructure.

We decided the project was going to be written in C# using .Net Core
and wanted the infrastructure to be as agile and flexible as possible. The simplest way to do this, was to use the MicroServices architecture.

MicroServices

The MicroService Infrastructure is an architecture that puts the focus on the idea of low coupling and high cohesion to the extreme, one might say.
Instead of just making different classes for different businesses logic, you separate them into different software units. (You can read more about this here).

The system was designed to contain many MicroServices. In turn, each of the MS was built as a “pyramid”.

In our project we don’t use the MS architecture 100% as advised. We have some shared business logic. In our case, it makes more sense rather than duplicating the code. We are able to make this kind of change due to the flexibility the MS gives us.
The way we chose to work still leaves the developer the freedom to change whatever he needs without disrupting other MSs.

The Pyramid

The bottom level of this pyramid, contains all the common stuff: Entities, helper methods, attributes, etc. All these libraries will be pushed to our local Nuget server (part II talks about this).

The second layer contains all the common services. This layer consists of all the business logic that is shared between all the MS. For example, reading the configuration from the AWS server.

The top of the pyramid is each MS specific business logic. This is what differs the different MSs. 

In order to all this to work as it should, one of out primary objective we set was very simple: Everything has to be as simple as possibly for a new developer to write new MSs and/or to maintain existing ones.

Starting from the “New project” phase, to the build phase, testing the software and finally deploying it.
The only way this could happen is if we make everything to work automatically.

The build pipeline is automatic and takes care of building, testing the code and, if necessary, pushing the new nupkgs to the local server.
Creating a new project will give you the first two phases of the pyramid automagically (Part III – Template-ing).
Lastly, with the magic of CI/CD, the deployment would never be easier.

Let’s start our journey with Part I – The .Net Core DI Container.