ViennaNET: Bibliothekenset für Backend

Hallo zusammen!

Wir sind die .NET-Entwicklergemeinschaft der Raiffeisenbank und möchten über eine Sammlung von Infrastruktur-Bibliotheken auf .NET Core berichten, die die schnelle Erstellung von Mikrodiensten mit einem einheitlichen Ökosystem ermöglichen. Wir haben sie als Open Source veröffentlicht!

Ein wenig Geschichte

Früher hatten wir ein großes monolithisches Projekt, das sich nach und nach in eine Sammlung von Mikrodiensten verwandelte (mehr über die Besonderheiten dieses Prozesses kann man lesen in diesem Artikel). Im Verlauf stießen wir auf das Problem, dass wir beim Erstellen neuer Mikrodienste oft verschiedene infrastrukturelle Lösungen kopieren mussten – etwa die Konfiguration des Loggings, den Umgang mit Datenbanken, WCF usw. An diesem Projekt arbeitete ein Team, und alle waren bereits an einen bestimmten etablierten Ansatz zur Arbeit mit der Infrastruktur gewöhnt. Daher haben wir den gemeinsamen Code in ein separates Repository ausgegliedert, die gesammelten Bibliotheken in Nuget-Pakete verpackt und in unser internes Nuget-Repository eingestellt.

Die Zeit verging, das Projekt wurde nach und nach zersplittert, es gab den Wunsch, neue Module der Client-Seite mit einem modernen Js-Framework zu erstellen und sie im Browser auszuführen. Wir begannen, von WCF/SOAP auf REST/HTTP umzusteigen, weshalb wir neue Bibliotheken benötigten, um Dienste basierend auf AspNet WebApi schnell zu starten. Die erste Version auf .Net Framework 4.5 wurde von unserem Architekten quasi im Alleingang in seiner Freizeit erstellt, aber sie erlaubte bereits 'Out of the Box', mit drei Zeilen in Program.cs einen Dienst zu starten, der die Authentifizierung (NTLM), Logging, Swagger, IoC/DI auf Basis von Castle Windsor, konfigurierte HTTP-Clients, die verschiedene Header für eine durchgängige Protokollierung im gesamten Projekt weiterleiteten, enthielt. Und all dies konnte auch zusätzlich direkt in der Konfigurationsdatei des Dienstes konfiguriert werden.

Allerdings war nicht alles reibungslos: Diese Bibliothek war äußerst unflexibel bei der Einführung neuer Module. Beispielsweise musste, wenn ein spezielles Middleware hinzugefügt werden sollte, eine neue Assembly erstellt und von der Basisklasse, die den Dienst startete, abgeleitet werden, was äußerst unpraktisch war. Glücklicherweise gab es nicht allzu viele solcher Fälle.

Das Zeitalter von Docker und Kubernetes

Es kam die Zeit, als auch wir von der Welle von Docker und Kubernetes erreicht wurden, die wir aufmerksam verfolgt haben: es war eine großartige Gelegenheit, den technologischen Fortschritt in .Net Core voranzutreiben. Das bedeutet, dass wir eine neue Infrastruktur für den Betrieb von Services benötigen: ein Teil der Bibliotheken wurde praktisch unverändert von .Net Framework auf .Net Standard und .Net Core übertragen, ein anderer Teil mit kleinen Verbesserungen. Am meisten wollten wir die Funktionen, die mit dem Start von Services in AspNet Core verbunden sind, überarbeiten.

An erster Stelle stand das Konzept, das den großen Nachteil der vorherigen Version beseitigen sollte: fehlende Flexibilität. Daher wurde beschlossen, das gesamte System von Bibliotheken so unabhängig und modular wie möglich zu gestalten und die erforderlichen Services wie ein Baukasten zusammenzustellen.

Das Hauptziel ist es, einen einheitlichen Ansatz zu schaffen, der beschreibt, wie man mit Datenbanken, Bus-Systemen und anderen Services interagiert. Wir haben darauf geachtet, dass die Integrationen schnell und schmerzfrei sind, sodass sich die Entwickler auf die Erstellung der Geschäftslogik und nicht auf die Infrastruktur konzentrieren können – diese ist bereits bereit. Das gemeinsame Repository trägt dazu bei, die Erfahrungen der Teammitglieder zu verbessern: Wenn sehr ähnliche interne Infrastrukturen verwendet werden, ist es einfacher, sich in den Entwicklungsprozess eines anderen Teams einzufinden und Fachwissen auszutauschen.

Und warum brauchen wir Open Source?

Wir möchten die Reife unserer Expertise zeigen und qualitativ hochwertiges Feedback erhalten: Eine Person von außerhalb der Bank wird etwas Eigenes einbringen können. Außerdem interessiert uns die Weiterentwicklung von Praktiken im Umgang mit Mikrodiensten und DDD im .NET Bereich in der Industrie – möglicherweise möchte jemand bestimmte Teile des Frameworks übernehmen.

Genau genommen, ViennaNET

Schauen wir uns das nun genauer an. Den vollständigen Quellcode haben wir hier abgelegt.

ViennaNET.WebApi.*

Dieses Bibliothekspaket besteht aus dem „Wurzel“-Element von ViennaNET.WebApi, das eine Builder-Klasse für den Service CompanyHostBuilder enthält, sowie einer Reihe von Konfiguratoren ViennaNET.WebApi.Configurators.*, von denen jeder es ermöglicht, bestimmte Funktionen zum erstellten Service hinzuzufügen und zu konfigurieren. Unter den Konfiguratoren finden Sie die Anbindung von Logging, Diagnostik, Authentifizierungs- und Autorisierungsarten, Swagger usw.

Hier enthält ViennaNET.WebApi.Runners.* vorkonfigurierte Service-Builder. Diese Pakete ermöglichen es, sich nicht jedes Mal daran zu erinnern, welche Konfiguratoren beim Erstellen eines neuen Dienstes eingebunden werden müssen. Dabei schränken sie die Funktionalität des Service-Builders in keinster Weise ein.

ViennaNET.Mediator.*

Bibliotheken, die es ermöglichen, einen internen Mediatortyp für Befehle und Anfragen innerhalb des Dienstes zu erstellen. Dieser Ansatz reduziert die Anzahl der DI-Injektionen auf bis zu eine, zum Beispiel in Controllern. Dadurch können verschiedene Dekoratoren zu Anfragen hinzugefügt werden, was deren Verarbeitung vereinheitlicht und den Code reduziert.

ViennaNET.Validation

Eine Assembly, die eine Reihe von Klassen zur Erstellung von Validierungsregeln und Sequenzen dieser Regeln enthält. Sehr nützlich für die Implementierung von Domänenvalidierungen, da es ermöglicht, jede Geschäftsbedingung als einfache und separate Regel zu beschreiben.

ViennaNET.Redis

Eine Bibliothek mit Wrappern, die eine bequeme Arbeit mit Redis als In-Memory-Cache ermöglicht.

ViennaNET.Specifications

Eine Assembly, die Klassen enthält, die das Muster „Spezifikation“ implementieren.

Das ist noch lange nicht alles, was unser Paket zu bieten hat. Weitere Informationen finden Sie im Repository auf GitHub. Bald planen wir die Veröffentlichung unserer Bibliotheken für die Arbeit mit Datenbanken als OpenSource.

Danke für Ihre Aufmerksamkeit, wir freuen uns auf Ihre Kommentare und Pull Requests.

Quelle: habr.com