ViennaNET: eine Sammlung von Bibliotheken für das Backend.

Hallo zusammen!

Wir sind die .NET-Entwicklergemeinschaft der Raiffeisenbank und möchten Ihnen eine Sammlung von Infrastruktur-Bibliotheken auf .NET Core vorstellen, die die schnelle Erstellung von Mikroservices in 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 allmählich in eine Reihe von Mikroservices verwandelte (über die Besonderheiten dieses Prozesses können Sie lesen in in diesem Artikel). Während dieses Prozesses stießen wir auf das Problem, dass wir bei der Erstellung neuer Mikroservices oft verschiedene infrastrukturelle Lösungen kopieren mussten – wie z.B. Logging-Einstellungen, Datenbankzugriffe, WCF usw. An diesem Projekt arbeitete ein Team, und alle hatten sich bereits an einen bestimmten Ansatz im Umgang mit der Infrastruktur gewöhnt. Daher haben wir den gemeinsamen Code in ein separates Repository ausgegliedert, die erstellten Bibliotheken in Nuget-Pakete verpackt und in unser internes Nuget-Repository eingefügt.

Die Zeit verging, das Projekt zerfiel allmählich, und der Wunsch entstand, neue Module für die clientseitige Anwendung 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 schnell auf der Grundlage von AspNet WebApi zu starten. Die erste Version auf .Net Framework 4.5 wurde von unserem Architekten quasi in seiner Freizeit zusammengestellt, doch sie ermöglichte bereits mit drei Zeilen in Program.cs den Start eines Services, der Authentifizierung (NTLM), Logging, Swagger, IoC/DI auf Basis von Castle Windsor, konfigurierte HTTP-Clients, die verschiedene Header für ein durchgängiges Logging im gesamten Projekt durchleiteten. All dies konnte zusätzlich direkt in der Konfigurationsdatei des Services eingestellt werden.

Doch nicht alles lief reibungslos: Diese Bibliothek erwies sich als äußerst unflexibel, wenn es um die Integration neuer Module ging. Wenn beispielsweise ein spezielles Middleware hinzugefügt werden sollte, musste eine neue Assembly erstellt werden, die von der Basisklasse abgeleitet war, die den Service startete, was äußerst umständlich war. Zum Glück gab es solche Fälle nicht allzu oft.

Die Ära von Docker und Kubernetes

Es ist an der Zeit, dass auch wir in den Genuss der Welle von Docker und Kubernetes kommen, die wir schon lange beobachtet haben: Es war eine großartige Gelegenheit, den Schritt zu moderneren Technologien wie .Net Core zu wagen. Daher benötigen wir eine neue Infrastruktur, um unsere Dienste bereitzustellen: Einige Bibliotheken wurden nahezu unverändert von .Net Framework auf .Net Standard und .Net Core übertragen, während andere mit kleineren Verbesserungen versehen wurden. Am meisten wollten wir jedoch die Funktionalitäten überarbeiten, die mit dem Start von Diensten auf AspNet Core verbunden sind.

Zunächst wurde ein Konzept in Betracht gezogen, das den Hauptnachteil der vorherigen Version beseitigt: fehlende Flexibilität. Daher wurde entschieden, das gesamte Bibliothekssystem so unabhängig und modular wie möglich zu gestalten und die erforderlichen Dienste wie ein Konstruktionsspielzeug zusammenzustellen.

Das Hauptziel ist es, einen einheitlichen Ansatz zu schaffen, der beschreibt, wie man mit Datenbanken, Bussen und anderen Diensten interagiert. Wir haben uns bemüht, die Integrationen schnell und reibungslos zu gestalten, sodass sich Entwickler auf das Schreiben von Geschäftslogik konzentrieren können, und nicht auf die Infrastruktur – diese ist bereits bereit. Das gemeinsame Repository trägt dazu bei, die Interaktion innerhalb der Teams zu verbessern: Wenn sehr ähnliche interne Infrastrukturen verwendet werden, fällt es leichter, in den Entwicklungsprozess eines anderen Teams einzusteigen und Expertise auszutauschen.

Und warum benötigen wir Open Source?

Wir möchten die Reife unserer Expertise zeigen und qualitativ hochwertiges Feedback erhalten: Eine Person außerhalb der Bank kann etwas Eigenes einbringen. Außerdem sind wir an der Entwicklung von Praktiken für die Arbeit mit Mikrodiensten und DDD auf .NET in der Industrie interessiert, möglicherweise möchte jemand bestimmte Teile des Frameworks mitnehmen.

Eigentlich, ViennaNET

Lassen Sie uns nun alles im Detail betrachten. Den vollständigen Quellcode finden Sie hier.

ViennaNET.WebApi.*

Dieses Bibliothekspaket besteht aus dem "Core" ViennaNET.WebApi, das eine Builder-Klasse für den Service CompanyHostBuilder enthält, sowie einer Reihe von Konfiguratoren in ViennaNET.WebApi.Configurators.*, die jeweils Funktionen zum erstellten Service hinzufügen und konfigurieren können. Unter diesen Konfiguratoren finden Sie Schnittstellen für Logging, Diagnostik, Authentifizierung und Autorisierung, Swagger usw.

Außerdem enthält ViennaNET.WebApi.Runners.* vorkonfigurierte Service-Builder. Diese Pakete verhindern, dass man sich jedes Mal erinnern muss, welche Konfiguratoren man beim Erstellen eines neuen Services anschließen sollte. Dabei schränken sie die Funktionalität des Service-Builders nicht ein.

ViennaNET.Mediator.*

Bibliotheken, die es ermöglichen, einen internen Mediator-Bus für Befehle und Anfragen innerhalb des Services zu erstellen. Dieser Ansatz reduziert die Anzahl der DI-Injektionen auf eine, zum Beispiel in den Controllern. Dadurch können verschiedene Dekoratoren für 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 deren Sequenzen enthält. Sehr nützlich für die Implementierung von Domain-Validierungen, da sie es ermöglicht, jede Geschäftsbedingung als einfache, separate Regel zu beschreiben.

ViennaNET.Redis

Eine Bibliothek mit Wrappern für die einfache Arbeit mit Redis als In-Memory-Cache.

ViennaNET.Specifications

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

Das ist bei weitem nicht alles, was in unserem Paket enthalten ist. Den Rest können Sie sich ansehen im Repository auf GitHub. Geplant ist bald die Veröffentlichung unserer Bibliotheken für die Arbeit mit Datenbanken als Open Source.

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

Quelle: habr.com