Hi all!
We are a community of .NET developers of Raiffeisenbank and we want to talk about a set of infrastructure libraries on .NET Core for quickly creating microservices with a single ecosystem. Brought it to Open Source!
A bit of history
Once we had a large monolithic project, which gradually turned into a set of microservices (you can read about the features of this process in ). In the process, we encountered the problem that when creating new microservices, we often had to copy various infrastructure solutions - such as setting up logging, working with a database, WCF, etc. One team worked on this project, and everyone was already used to some well-established approach to working with infrastructure. Therefore, we separated the common code into a separate repository, wrapped the collected libraries into Nuget packages and placed them in our internal Nuget repository.
Time passed, the project was gradually split up, there was a desire to create new client-side modules on a modern Js-framework and run them in the browser. We started migrating from WCF/SOAP to REST/HTTP, so we needed new libraries to quickly start services based on AspNet WebApi. The first version on the .Net Framework 4.5 was made by our architect almost on his knee in his spare time, but it already out of the box allowed three lines in Program.cs to launch a service that contained authorization (NTLM), logging, Swagger, IoC / DI on based on Castle Windsor, configured HTTP clients that forward various headers to provide end-to-end logging throughout the project. And the whole thing could be additionally configured already directly in the service configuration file.
However, not everything went smoothly: this library turned out to be extremely inflexible in terms of introducing new modules. For example, if you needed to add some special middleware, then you had to create a new assembly and inherit from the base class that starts the service, which was extremely inconvenient. Fortunately, there were not many such cases.
The Age of Docker and Kubernetes
The time came when the wave of Docker and Kubernetes came to us, which we closely watched: after all, it was a great chance to start moving further in technology, in .Net Core. This means that we will need a new infrastructure for running services: some of the libraries migrated from the .Net Framework to .Net Standard and .Net Core with virtually no changes, some with minor improvements. But most of all I wanted to rework the functionality associated with launching services on AspNet Core.
First of all, the concept was considered, which allows to remove the main drawback of the previous version: the lack of flexibility. Therefore, it was decided to make the entire system of libraries as independent and modular as possible and collect the services necessary for functionality as a constructor.
The main goal is to create a unified approach that describes how to interact with databases, buses, and other services. We tried to make integrations quick and painless, and developers could concentrate on writing business logic, not infrastructure - it is already ready. A shared repository helps improve the experience of collaboration within teams: when very similar internal infrastructures are used, it is easier to get involved in the development process of another team and exchange expertise.
And why do we need Open Source?
We want to show the maturity of the expertise and get high-quality feedback: a person who is outside the bank will be able to bring something of himself. We are also interested in the development of practices for working with microservices and DDD on .NET in the industry, perhaps someone will want to take certain parts of the framework to themselves.
Actually, ViennaNET
Now let's look at everything in more detail. .
ViennaNET.WebApi.*
This set of libraries consists of the "root" ViennaNET.WebApi, which contains the builder class for the CompanyHostBuilder service, and the set of ViennaNET.WebApi.Configurators.* configurators, each of which allows you to add and configure some functionality to the created service. Among the configurators, you can find the connection of logging, diagnostics, type of authentication and authorization, swagger, etc.
Immediately ViennaNET.WebApi.Runners.* contains preconfigured service builders. These packages allow you not to remember every time you create a new service which configurators need to be connected. However, they do not restrict the functionality of the service builder in any way.
ViennaNET.Mediator.*
Libraries that allow you to create an internal intermediary bus for commands and requests within the service. This approach allows you to reduce the number of DI injections to one, for example, in controllers. Due to this, you can add various decorators to requests, which unifies their processing and reduces the amount of code.
ViennaNET.Validation
An assembly containing a set of classes for creating validation rules and sequences from them. It is very convenient for implementing domain validation, as it allows you to describe each business condition as a simple and separate rule.
ViennaNET.Redis
A library with wrappers for convenient work with Redis as an in-memory cache.
ViennaNET.Specifications
An assembly that contains classes that implement the Specification pattern.
This is not all that is in our set. The rest can be seen . We plan to release our libraries for working with databases in OpenSource soon.
Thank you for your attention, we are waiting for your comments and pull requests.
Source: habr.com