booking-microservices-sample - Booking Microservicesは、チケットを予約するためのサンプルアプリケーションです。このアプリケーションは、.Net Core、CQRS、DDD、Vertical Slice Architecture、Docker、kubernetes、tye、masstransit、RabbitMQ、Grpc、yarpリバースプロキシ、Identity Server、Redis、SqlServer、Entity Framework Core、Eventなどのさまざまなソフトウェアアーキテクチャとテクノロジーに基づいていますソーシングと…

(Booking Microservices is a Sample application for booking ticket. This application based on different software architecture and technologies like .Net Core, CQRS, DDD, Vertical Slice Architecture, Docker, kubernetes, tye, masstransit, RabbitMQ, Grpc, yarp reverse proxy, Identity Server, Redis, SqlServer, Entity Framework Core, Event Sourcing and different level of testing.)

Created at: 2022-05-07 22:12:15
Language: C#
License: MIT

ライセンス:MIT

予約-マイクロサービス-サンプル

Booking Microservicesは、チケットを予約するためのサンプルアプリケーションです。このアプリケーションは、.Net Core、CQRS、DDD、Vertical Slice Architecture、Docker、kubernetes、tye、masstransit、RabbitMQ、Grpc、yarpリバースプロキシ、Identity Server、Redis、SqlServer、Entity Framework Core、Eventなどのさまざまなソフトウェアアーキテクチャとテクノロジーに基づいていますソーシングとさまざまなレベルのテスト。

🌀このリポジトリは進行中であり、時間の経過とともに完成することに注意してください🚀

目次

このプロジェクトの目標

  • マイクロサービスは
    Domain Driven Design (DDD)
    実装に基づいています。
  • separation of bounded contexts
    マイクロサービスごとに修正します。
  • MessageBus
    非同期とを介した境界コンテキスト間の通信
    events
  • シンプルな
    CQRS
    実装とイベント駆動型アーキテクチャ。
  • Best Practice
    and
    New Technologies
    とを使用し
    Design Patterns
    ます。
  • Docker-Compose
    および
    Kubernetes
    を展開メカニズムに使用します。
  • Unit Testing
    、などのさまざまなタイプのテストを実装し
    Integration Testing
    ます。

プラン

このプロジェクトは進行中です。新しい機能は時間の経過とともに追加されます。

忘れないように、また将来の作品を追跡するために、作品のいくつかの問題を登録しようと思います。

TODO

高レベルの計画は表に示されています

特徴 状態
APIゲートウェイ 完了✔️
アイデンティティサービス 完了✔️
フライトサービス 完了✔️
旅客サービス 完了✔️
予約サービス 完了✔️
ビルディングブロック 進行中👷‍♂️

テクノロジー-図書館

  • ✔️
    .NET 6
    -.NETFrameworkおよび.NETCore(ASP.NETおよびASP.NET Coreを含む)
  • ✔️
    MVC Versioning API
    -サービスAPIのバージョン管理をASP.NETWebAPI、ASP.NET Web APIを使用したOData、およびASP.NETCoreに追加するライブラリのセット
  • ✔️
    EF Core
    -.NET用の最新のオブジェクトデータベースマッパー。LINQクエリ、変更の追跡、更新、およびスキーマの移行をサポートします
  • ✔️
    Masstransit
    -.NET用の分散アプリケーションフレームワーク。
  • ✔️
    MediatR
    -.NETでのシンプルで野心的なメディエーターの実装。
  • ✔️
    FluentValidation
    -強く型付けされた検証ルールを構築するための人気のある.NET検証ライブラリ
  • ✔️
    Swagger & Swagger UI
    -ASP.NETCore上に構築されたAPIを文書化するためのSwaggerツール
  • ✔️
    Serilog
    -完全に構造化されたイベントを使用した単純な.NETロギング
  • ✔️
    Polly
    --Pollyは、.NETの復元力と一時的な障害処理ライブラリであり、開発者は、再試行、サーキットブレーカー、タイムアウト、バルクヘッド分離、フォールバックなどのポリシーを流暢でスレッドセーフな方法で表現できます。
  • ✔️
    Scrutor
    -Microsoft.Extensions.DependencyInjectionのアセンブリスキャンおよび装飾拡張機能
  • ✔️
    Opentelemetry-dotnet
    -OpenTelemetry.NETクライアント
  • ✔️
    DuendeSoftware IdentityServer
    -ASP.NETCore用の最も柔軟で標準に準拠したOpenIDConnectおよびOAuth2.xフレームワーク
  • ✔️
    EasyCaching
    -キャッシングの基本的な使用法といくつかの高度な使用法を含むオープンソースのキャッシングライブラリ。これにより、キャッシングをより簡単に処理できます。
  • ✔️
    Mapster
    -.NETのコンベンションベースのオブジェクト-オブジェクトマッパー。
  • ✔️
    Hellang.Middleware.ProblemDetails
    -.NetCoreで例外を処理するためのミドルウェア
  • ✔️
    IdGen
    -.Net用のTwitterスノーフレークに似たIDジェネレーター
  • ✔️
    Yarp
    -.NETで高速プロキシサーバーを構築するためのリバースプロキシツールキット
  • ✔️
    Tye
    -マイクロサービスと分散アプリケーションの開発、テスト、デプロイを容易にする開発者ツール
  • ✔️
    MagicOnion
    -.NET、.NET Core、Unity用のgRPCベースのHTTP /2RPCストリーミングフレームワーク。
  • ✔️
    EventStore
    -複合イベント処理を備えたオープンソースの機能データベース。
  • ✔️
    MongoDB.Driver
    --MongoDB用の.NETドライバー。

ドメインと境界コンテキスト-サービス境界

  • Identity Service
    :Identity Serviceは、 IdentityServerを使用してユーザーを認証および承認するための制限されたコンテキストです。また、このサービスは、 .Net Core IdentityとJwtの認証と承認を使用して、ユーザーとそれに対応する役割と権限を作成する責任があります。

  • Flight Service
    :フライトサービスは、フライトに関連するすべての操作の制限されたコンテキストであり、利用可能なファイルと座席を取得します。

  • Passenger Service
    :Passenger Serviceは、乗客情報を管理し、アクティビティを追跡し、在庫切れの製品の通知を受け取るためにサブスクライブするための制限されたコンテキストです。

  • Booking Service
    :予約サービスは、チケットの予約に関連するすべての操作を管理するための制限されたコンテキストです。

プロジェクトの構造

対応するマイクロサービスへの同期および非同期リクエストのルートにyarpリバースプロキシを使用しました。また、各マイクロサービスには、データベースやファイルなどの独自のビジネスと依存関係があり、各マイクロサービスは他のマイクロサービスから切り離され、個別に開発およびデプロイされます。これらのマイクロサービスは、RestやgRpcなどの同期呼び出しで相互に通信し、非同期呼び出しにRabbitMqまたはKafkaを使用します。

認証と承認用に個別のマイクロサービス(IdentityServer)があり、各リクエストはAPI Gatewayに送信されてからIdentityマイクロサービスにルーティングされ、認証と承認後にAPIGatewayに戻って期待されるマイクロサービスにルーティングされます。

また、ここでは、結果整合性メカニズムを使用して、マイクロサービス間の非同期通信用のMessageBrokerとしてRabbitMQを使用しました。その上、 MassTransitを使用すると、メッセージング、可用性、信頼性などのマイクロサービスプロジェクトで多くの要件が提供されます。

マイクロ

event based
サービスとは、セットアップで発生するイベントを公開および/またはサブスクライブできることを意味します。このアプローチをサービス間の通信に使用することにより、各マイクロサービスは他のサービスについて知る必要がなく、他のマイクロサービスで発生したエラーを処理する必要もありません。

また、クラスを使用する代わりに、コントローラーでMediatRライブラリを使用してメディエーターパターンを使用しました。これは、クラスを使用する代わりに、コントローラーがさまざまなサービスに依存し、これが単一責任の原則に違反するためです。ハンドラーパターンを使用して、ハンドラーへのメッセージの配信を管理します。メディエーターパターンの背後にある利点の1つは、アプリケーションコードがリクエストのアクティビティのパイプラインを定義できることです。たとえば、コントローラーでコマンドを作成してメディエーターに送信すると、メディエーターはコマンドをアプリケーション層の特定のコマンドハンドラーにルーティングします。

application service

単一責任の原則をサポートし、自分自身を繰り返さないという原則をサポートするために、横断的関心事の実装は、mediatrパイプラインの動作を使用するか、 mediatrデコレーターを作成して行われます。

また、このプロジェクトでは、クリーンアーキテクチャ垂直スライスアーキテクチャを組み合わせて使用​​しました。また、このプロジェクトではフィーチャフォルダ構造を使用しました。

また、ここでは、cqrsを使用して、機能をアプリケーションを作成する非常に小さな部分に分解しました。

  • パフォーマンス、スケーラビリティ、およびシンプルさを最大化します。
  • adding new feature to this mechanism is very easy without any breaking change in other part of our codes. New features only add code, we're not changing shared code and worrying about side effects.
  • easy to maintain and any changes only affect on one command or query and avoid any breaking changes on other parts
  • it gives us better separation of concerns and cross cutting concern (with help of mediatr behavior pipelines) in our code instead of a big service class for doing a lot of things.

I treat each request as a distinct use case or slice, encapsulating and grouping all concerns from front-end to back. When adding or changing a feature in an application in n-tire architecture, we are typically touching many different "layers" in an application. we are changing the user interface, adding fields to models, modifying validation, and so on. Instead of coupling across a layer, we couple vertically along a slice. we

Minimize coupling
between slices
, and
maximize coupling
in a slice
.

With this approach, each of our vertical slices can decide for itself how to best fulfill the request. New features only add code, we're not changing shared code and worrying about side effects.

With using CQRS pattern, we cut each business functionality into some vertical slices, and inner each of this slices we have technical folders structure specific to that feature (command, handlers, infrastructure, repository, controllers, ...). In Our CQRS pattern each command/query handler is a separate slice. This is where you can reduce coupling between layers. Each handler can be a separated code unit, even copy/pasted. Thanks to that, we can tune down the specific method to not follow general conventions (e.g. use custom SQL query or even different storage). In a traditional layered architecture, when we change the core generic mechanism in one layer, it can impact all methods.

How to Run

Config Certificate

Runt the following commands for Config SSL in your system

dotnet dev-certs https -ep %USERPROFILE%\.aspnet\https\aspnetapp.pfx -p {password here}
dotnet dev-certs https --trust

注:代わりにこのコマンドを

powershell
使用して実行する場合
$env:USERPROFILE
%USERPROFILE%

DockerCompose

アプリケーションのルートで次のコマンドを使用して、このdocker-compose.yamlファイルを使用してdockerでこのアプリを実行します。

docker-compose -f ./deployments/docker-compose/docker-compose.yaml up -d

ドキュメントAPI

APIをテストするために、VSCodeのRESTクライアントプラグインを使用しました。このファイルbooking.restはプロジェクトのルートにあります。また、APIを実行した後、/swaggerルートパス内のすべてのマイクロサービスのswaggeropenapiにアクセスできます。

サポート

私の作品が気に入ったら、お気軽に次のことを行ってください。

  • このリポジトリ。そして、私たちは一緒に幸せになります:)

私をサポートしてくれてありがとう!

貢献

貢献はいつでも大歓迎です!まず、投稿ガイドラインのページをご覧ください。

すべての貢献者のおかげで、あなたは素晴らしく、あなたなしでは不可能です!目標は、非常によく知られているリソースの分類されたコミュニティ主導のコレクションを構築することです。

プロジェクトの参照とクレジット