ViennaNET: バックエンド用のライブラリのセット

みなさん、こんにちは!

私たちはライファイゼンバンクの .NET 開発者のコ​​ミュニティであり、単一のエコシステムでマイクロサービスを迅速に作成するための .NET Core に基づく一連のインフラストラクチャ ライブラリについて話したいと考えています。 彼らはそれをオープンソースに持ち込んだのです!

ViennaNET: バックエンド用のライブラリのセット

歴史を少し

かつて、私たちには大規模なモノリシック プロジェクトがありましたが、それは徐々に一連のマイクロサービスに変わりました (このプロセスの機能については、次の記事を参照してください)。 この記事)。 その過程で、新しいマイクロサービスを作成するときに、ログの設定、データベース、WCF の操作など、さまざまなインフラストラクチャ ソリューションをコピーしなければならないことが多いという問題に遭遇しました。 あるチームがこのプロジェクトに取り組み、全員がインフラストラクチャを扱うための確立されたアプローチにすでに慣れていました。 したがって、共通のコードを別のリポジトリに分離し、収集したライブラリを Nuget パッケージにラップして、内部の Nuget リポジトリに配置しました。

時間が経ち、プロジェクトは徐々に細分化され、最新の JS フレームワークで新しいクライアント側モジュールを作成し、ブラウザで実行したいという要望が生じました。 WCF/SOAP から REST/HTTP への移行を開始したため、AspNet WebApi に基づくサービスを迅速に起動するための新しいライブラリが必要でした。 .Net Framework 4.5 の最初のバージョンは、私たちのアーキテクトが暇なときにほぼ膝の上で作成したものですが、すぐに使用できるようになり、Program.cs 内の XNUMX 行で認証 (NTLM) を含むサービスを起動できるようになりました。 Castle Windsor に基づくロギング、Swagger、IoC/DI、さまざまなヘッダーを転送してプロジェクト全体にわたってエンドツーエンドのロギングを提供するカスタマイズされた HTTP クライアント。 さらに、このすべてをサービス構成ファイルで直接構成することもできます。

ただし、すべてがスムーズだったわけではありません。このライブラリは、新しいモジュールの導入に関して非常に柔軟性に欠けていることが判明しました。 たとえば、特別なミドルウェアを追加する必要がある場合、新しいアセンブリを作成し、サービスを実行する基本クラスから継承する必要がありましたが、これは非常に不便でした。 幸いなことに、そのようなケースはそれほど多くありませんでした。

DockerとKubernetesの時代

Docker と Kubernetes の波が私たちに到来する時が来ました。私たちはそれを注意深く観察していました。結局のところ、.Net Core のテクノロジーに沿ってさらに前進し始める絶好のチャンスでした。 これは、サービスを実行するために新しいインフラストラクチャが必要になることを意味します。一部のライブラリは実質的に変更なしで .Net Framework から .Net Standard および .Net Core に移行しましたが、一部のライブラリは若干の改善が加えられています。 しかし、何よりも私がやりたかったのは、AspNet Core でのサービスの起動に関連する機能です。

私たちが最初に検討したのは、以前のバージョンの主な欠点である柔軟性の欠如を取り除くコンセプトでした。 そこで、ライブラリ システム全体を可能な限り独立かつモジュール化し、機能に必要なサービスをコンストラクターとして収集することにしました。

主な目標は、データベース、バス、その他のサービスと対話する方法を説明する統一されたアプローチを作成することです。 私たちは統合を迅速かつ苦痛なく行えるように努め、開発者はインフラストラクチャではなくビジネス ロジックの作成に集中できるようにしました。すでに準備が整っています。 共通のリポジトリは、チーム内の対話エクスペリエンスを向上させるのに役立ちます。非常に類似した内部インフラストラクチャが使用されている場合、別のチームの開発プロセスに参加して専門知識を交換することが容易になります。

そして、なぜオープンソースが必要なのでしょうか?

私たちは専門知識の成熟度を示し、質の高いフィードバックを受け取りたいと考えています。銀行の外にいる人でも、自分自身の何かをもたらすことができるのです。 また、業界内で .NET 上でマイクロサービスと DDD を操作するためのプラクティスの開発にも関心があり、おそらく誰かがフレームワークの特定の部分を引き継ぎたいと考えるでしょう。

実は、ViennaNET

では、詳しく見てみましょう。 完全なソースコードはここに掲載されています.

ViennaNET.WebApi.*

このライブラリのセットは、CompanyHostBuilder サービスのビルダー クラスを含む「ルート」の ViennaNET.WebApi と、コンフィギュレーターのセット ViennaNET.WebApi.Configurators.* で構成されます。各コンフィギュレーターにより、作成されたライブラリーにいくつかの機能を追加および構成できます。サービス。 コンフィギュレータの中には、ロギング、診断、認証と認可のタイプ、Swagger などの接続があります。

ViennaNET.WebApi.Runners.* には、事前構成されたサービス ビルダーも含まれています。 これらのパッケージを使用すると、新しいサービスを作成するたびにどのコンフィギュレータに接続する必要があるかを覚えておく必要がなくなります。 ただし、サービス ビルダーの機能はいかなる形でも制限されません。

ViennaNET.Mediator.*

サービス内のコマンドとリクエスト用の内部中間バスを作成できるライブラリ。 このアプローチにより、たとえばコントローラーでの DI インジェクションの数を XNUMX つに減らすことができます。 このため、リクエストにさまざまなデコレータを追加できるため、リクエストの処理が統合され、コードの量が削減されます。

ViennaNET.検証

検証ルールとそのルールからシーケンスを作成するためのクラスのセットを含むアセンブリ。 これにより、各ビジネス条件を単純な個別のルールの形式で記述することができるため、ドメイン検証を実装するのに非常に便利です。

ViennaNET.Redis

Redis をメモリ内キャッシュとして便利に操作するためのラッパーを備えたライブラリ。

ViennaNET.仕様

仕様パターンを実装するクラスを含むアセンブリ。

セットに含まれるものはこれだけではありません。 残りはご覧いただけます GitHub リポジトリ内。 データベースを操作するためのライブラリを近々オープンソースにリリースする予定です。

ご清聴ありがとうございます。コメントやプルリクエストをお待ちしております。

出所: habr.com

コメントを追加します