Web API を使用してマイクロサービスアプリケーションレイヤーを実装する

[アーティクル]
03/29/2023

ヒント

このコンテンツは eBook の「コンテナー化された .NET アプリケーションの .NET マイクロサービスアーキテクチャ」からの抜粋です。.NET Docs で閲覧できるほか、PDF として無料ダウンロードすると、オンラインで閲覧できます。

PDF のダウンロード

依存関係挿入を使用し、アプリケーションレイヤーにインフラストラクチャオブジェクトを挿入する

前のセクションで述べたように、アプリケーションレイヤーは、Web API プロジェクトや MVC Web アプリプロジェクトなどで作成する成果物 (アセンブリ) の一部として実装できます。 ASP.NET Core を使用して作成されたマイクロサービスの場合、アプリケーションレイヤーは通常、Web API ライブラリになります。 ASP.NET Core から来るもの (そのインフラストラクチャとコントローラー) を、カスタムアプリケーションレイヤーコードと分離したい場合は、アプリケーションレイヤーを別のクラスライブラリに配置することもできますが、これは任意です。

たとえば、注文マイクロサービスのアプリケーションレイヤーコードは、Ordering.API プロジェクト (ASP.NET Core Web API プロジェクト) の一部として直接実装されます (図 7-23 を参照)。

Screenshot of the Ordering.API microservice in the Solution Explorer.

図 7-23. Ordering.API ASP.NET Core Web API プロジェクト内のアプリケーションレイヤー

ASP.NET Core には、コンストラクター挿入を既定でサポートするシンプルな組み込み IoC コンテナー (IServiceProvider インターフェイスによって表されます) が含まれています。ASP.NET では、DI によって特定のサービスを利用可能にすることができます。 ASP.NET Core では、ユーザーが登録する型のうち、DI を通じて挿入されるものをサービスという用語で表します。組み込みコンテナーのサービスは、アプリケーションの Program.cs ファイルに構成します。依存関係は、型に必要であり、IoC コンテナーに登録するサービス内に実装されます。

ユーザーは通常、インフラストラクチャオブジェクトを実装する依存関係を挿入します。挿入する依存関係として典型的なのは、リポジトリです。ただし、インフラストラクチャの依存関係が他にもある場合は、それらを挿入することもできます。単純な実装の場合は、作業単位パターンオブジェクト (EF DbContext オブジェクト) を直接実装することもできます。なぜなら、DBContext はインフラストラクチャ永続オブジェクトの実装でもあるからです。

次の例では、.NET において、必要なリポジトリオブジェクトがコンストラクターを通じてどのように挿入されるかが示されています。このクラスは、次のセクションで取り上げるコマンドハンドラーです。

public class CreateOrderCommandHandler
        : IRequestHandler<CreateOrderCommand, bool>
{
    private readonly IOrderRepository _orderRepository;
    private readonly IIdentityService _identityService;
    private readonly IMediator _mediator;
    private readonly IOrderingIntegrationEventService _orderingIntegrationEventService;
    private readonly ILogger<CreateOrderCommandHandler> _logger;

    // Using DI to inject infrastructure persistence Repositories
    public CreateOrderCommandHandler(IMediator mediator,
        IOrderingIntegrationEventService orderingIntegrationEventService,
        IOrderRepository orderRepository,
        IIdentityService identityService,
        ILogger<CreateOrderCommandHandler> logger)
    {
        _orderRepository = orderRepository ?? throw new ArgumentNullException(nameof(orderRepository));
        _identityService = identityService ?? throw new ArgumentNullException(nameof(identityService));
        _mediator = mediator ?? throw new ArgumentNullException(nameof(mediator));
        _orderingIntegrationEventService = orderingIntegrationEventService ?? throw new ArgumentNullException(nameof(orderingIntegrationEventService));
        _logger = logger ?? throw new ArgumentNullException(nameof(logger));
    }

    public async Task<bool> Handle(CreateOrderCommand message, CancellationToken cancellationToken)
    {
        // Add Integration event to clean the basket
        var orderStartedIntegrationEvent = new OrderStartedIntegrationEvent(message.UserId);
        await _orderingIntegrationEventService.AddAndSaveEventAsync(orderStartedIntegrationEvent);

        // Add/Update the Buyer AggregateRoot
        // DDD patterns comment: Add child entities and value-objects through the Order Aggregate-Root
        // methods and constructor so validations, invariants and business logic
        // make sure that consistency is preserved across the whole aggregate
        var address = new Address(message.Street, message.City, message.State, message.Country, message.ZipCode);
        var order = new Order(message.UserId, message.UserName, address, message.CardTypeId, message.CardNumber, message.CardSecurityNumber, message.CardHolderName, message.CardExpiration);

        foreach (var item in message.OrderItems)
        {
            order.AddOrderItem(item.ProductId, item.ProductName, item.UnitPrice, item.Discount, item.PictureUrl, item.Units);
        }

        _logger.LogInformation("----- Creating Order - Order: {@Order}", order);

        _orderRepository.Add(order);

        return await _orderRepository.UnitOfWork
            .SaveEntitiesAsync(cancellationToken);
    }
}

このクラスは、挿入されたリポジトリを使用してトランザクションを実行し、状態の変更を保持します。このクラスがコマンドハンドラーなのか、ASP.NET Core Web API コントローラーメソッドなのか、それとも DDD アプリケーションサービスなのかは重要ではありません。重要なのは、このクラスがリポジトリ、ドメインエンティティ、およびその他のアプリケーション調整をコマンドハンドラーのような方法で使用する、単純なクラスだということです。依存関係挿入は、コンストラクターベースの DI を使用したこの例のように、記述されたすべてのクラスに対して同様に動作します。

依存関係実装の型とインターフェイス (または抽象化) の登録

コンストラクターを通じて挿入されたオブジェクトを使用するには、まず、DI を通じてアプリケーションクラスに挿入されたオブジェクトの生成元となるインターフェイスやクラスを、どこに登録するのかを知る必要があります (先の例で示したコンストラクターベースの DI と同様)。

ASP.NET Core で提供される組み込み IoC コンテナーの使用

ASP.NET Core によって提供される組み込み IoC コンテナーを使用する場合は、Program.cs ファイルに挿入する型を次のコードで登録します。

// Register out-of-the-box framework services.
builder.Services.AddDbContext<CatalogContext>(c =>
    c.UseSqlServer(Configuration["ConnectionString"]),
    ServiceLifetime.Scoped);

builder.Services.AddMvc();
// Register custom application dependencies.
builder.Services.AddScoped<IMyCustomRepository, MyCustomSQLRepository>();

IoC コンテナーに型を登録する場合の最も一般的なパターンは、型のペア (インターフェイスとその関連実装クラス) を登録するやり方です。その後、任意のコンストラクターを通じて IoC コンテナーからオブジェクトを要求する際に、特定のインターフェイス型のオブジェクトを要求します。たとえば、先の例の最後の行では、いずれかのコンストラクターに IMyCustomRepository (インターフェイスまたは抽象型) への依存関係がある場合に、IoC コンテナーが MyCustomSQLServerRepository 実装クラスのインスタンスを挿入するよう記述されています。

自動登録用の Scrutor ライブラリの使用

.NET で DI を使用するときに、アセンブリをスキャンし、その型を規則によって自動的に登録できるようにしたい場合があります。この機能は、現在 ASP.NET Coreでは使用できません。ただし、この目的のために Scrutor ライブラリを使用することはできます。この方法は、IoC コンテナーに登録する必要がある型がたくさんある場合に便利です。

その他の技術情報

Matthew King。 Scrutor でのサービスの登録
https://www.mking.net/blog/registering-services-with-scrutor
Kristian Hellang。 Scrutor。 GitHub リポジトリ。
https://github.com/khellang/Scrutor

Autofac を IoC コンテナーとして使用する

eShopOnContainers の注文マイクロサービスのように、追加の IoC コンテナーを使用し、Autofac を使用する ASP.NET Core パイプラインにそれらをプラグインすることもできます。 Autofac を使用する場合は通常、モジュールを通じて型を登録します。これにより、型がどこにあるかに応じて、複数のファイル間で登録型を分割することができます (複数のクラスライブラリ間でアプリケーション型を分散できたのと同様)。

たとえば、次の例では、挿入する型を Ordering.API Web API プロジェクト用の Autofac アプリケーションモジュールに記述しています。

public class ApplicationModule : Autofac.Module
{
    public string QueriesConnectionString { get; }
    public ApplicationModule(string qconstr)
    {
        QueriesConnectionString = qconstr;
    }

    protected override void Load(ContainerBuilder builder)
    {
        builder.Register(c => new OrderQueries(QueriesConnectionString))
            .As<IOrderQueries>()
            .InstancePerLifetimeScope();
        builder.RegisterType<BuyerRepository>()
            .As<IBuyerRepository>()
            .InstancePerLifetimeScope();
        builder.RegisterType<OrderRepository>()
            .As<IOrderRepository>()
            .InstancePerLifetimeScope();
        builder.RegisterType<RequestManager>()
            .As<IRequestManager>()
            .InstancePerLifetimeScope();
   }
}

Autofac には、アセンブリをスキャンし、命名規則で型を登録する機能もあります。

登録プロセスと概念は、組み込みの ASP.NET Core IoC コンテナーに型を登録する方法とよく似ていますが、Autofac を使用する場合は構文が少し異なります。

このコード例では、IOrderRepository 抽象化が、実装クラス OrderRepository と共に登録されています。つまり、コンストラクターが IOrderRepository 抽象化またはインターフェイスを通じて依存関係を宣言している場合、IoC コンテナーは OrderRepository クラスのインスタンスを挿入するということです。

同じサービスや依存関係に対する要求間でインスタンスがどのように共有されるかは、インスタンススコープ型によって決まります。依存関係に対する要求が行われた場合、IoC コンテナーは次のいずれかの結果を返します。

有効期間範囲ごとに 1 つのインスタンス (ASP.NET Core IoC コンテナー内で scoped として参照されます)。
依存関係ごとに 1 つの新規インスタンス (ASP.NET Core IoC コンテナー内で transient として参照されます)。
IoC コンテナーを使用してすべてのオブジェクト間で共有される 1 つのインスタンス (ASP.NET Core IoC コンテナー内で singleton として参照されます)。

その他の技術情報

ASP.NET Core での依存関係の挿入の概要
https://learn.microsoft.com/aspnet/core/fundamentals/dependency-injection
Autofac。 公式ドキュメント。
https://docs.autofac.org/en/latest/
ASP.NET Core IoC コンテナーサービスの有効期間と Autofac IoC コンテナーインスタンスの範囲の比較 - Cesar de la Torre
https://devblogs.microsoft.com/cesardelatorre/comparing-asp-net-core-ioc-service-life-times-and-autofac-ioc-instance-scopes/

コマンドおよびコマンドハンドラーパターンの実装

前のセクションで示したコンストラクターベースの DI の例では、IoC コンテナーはクラス内のコンストラクターを通じてリポジトリを挿入していました。ですが、これらは厳密にはどこに挿入されたのでしょうか。シンプルな Web API (たとえば、eShopOnContainers 内のカタログマイクロサービス) では、ASP.NET Core の要求パイプラインの一部として、MVC コントローラーレベル (コントローラーのコンストラクター内) でこれらを挿入します。しかし、このセクションの最初のコード (eShopOnContainers 内の Ordering.API サービスの CreateOrderCommandHandler クラス) では、特定のコマンドハンドラーのコンストラクターを通じて依存関係の挿入が行われています。そこで、コマンドハンドラーとは何か、またどのような理由で使用するのかについて説明していきましょう。

コマンドパターンは本来、このガイドの前の方で説明した、CQRS パターンに関連するものです。 CQRS には 2 つの面があります。 1 つ目の領域はクエリです。簡略化されたクエリを、Dapper のマイクロ ORM と共に使用します。 2 つ目の領域はコマンドです。これは、トランザクションの開始点となるものであり、サービス外部からの入力チャネルとなるものです。

図 7-24 に示すように、パターンはクライアント側からのコマンドを受け入れ、ドメインモデルルールに基づいてそれらを処理し、最後にトランザクションで状態を保持することに基づいています。

Diagram showing the high-level data flow from the client to database.

図 7-24. コマンド (CQRS パターンの "トランザクション側") の概要

図 7-24 では、UI アプリは API 経由で CommandHandler にコマンドを送信します。これは、ドメインモデルとインフラストラクチャに依存し、データベースが更新されます。

コマンドクラス

コマンドは、システムの状態を変更するアクションを実行するための、システムへの要求です。コマンドは命令型であり、1 回だけ処理されます。

コマンドは命令型なので、通常は命令的な動詞 ("create" や "update" など) で名前が付けられ、集約型 (CreateOrderCommand など) が含められます。イベントと違って、コマンドは過去のファクトを指すものではありません。単なる要求なので、拒否される場合もあります。

コマンドは、ユーザーが要求を開始した結果として UI から発生することもありますし、プロセスマネージャーが操作実行のための集約を指定した場合には、プロセスマネージャーから発生することもあります。

コマンドの重要な特性は、単一のレシーバーによって 1 回だけ処理されなければならないという点です。つまりコマンドとは、アプリケーション内で実行する、単一のアクションまたはトランザクションであるということです。たとえば、同一の注文作成コマンドを 2 回以上処理することはできません。これは、コマンドとイベントの重要な違いです。イベントは、複数回処理される場合があります。なぜなら、さまざまなシステムやマイクロサービスがそのイベントに関連している可能性があるからです。

もう 1 つ重要なことは、コマンドがべき等ではない場合、そのコマンドは 1 回だけ処理されるという点です。コマンドを複数回実行しても、コマンドの性質上、またはシステムでのコマンドの処理方法上、その結果が変わらない場合には、そのコマンドはべき等であるということになります。

ドメインのビジネスルールやインバリアントに対して合理的である場合には、コマンドや更新プログラムをべき等にすることをお勧めします。たとえば、同じ例で言うと、何らかの理由 (再試行ロジックやハッキングなど) によって、同じ CreateOrder コマンドがシステムに複数回アクセスする場合には、そのコマンドを識別し、複数の注文が作成されないようにする必要があります。そのためには、操作に何らかの ID をアタッチして、コマンドや更新プログラムが既に処理されていないかどうかを識別する必要があります。

コマンドは単一のレシーバーに送信します。つまり、コマンドは発行するものではありません。発行は、何かが起こり、それがイベントレシーバーに関連する可能性がある場合に、そのファクトを記述したイベントに対して行うものです。イベントの場合、パブリッシャーはイベントをどのレシーバーが取得するかや、それに対してレシーバーがどう対応するかについて、一切関知しません。ただし、ドメインまたは統合イベントは前のセクションで既に説明した別のトピックです。

コマンドは、データフィールドやコレクションのほか、コマンドを実行するために必要なすべての情報を含んだクラスを使用して実装されます。コマンドは特別な種類のデータ転送オブジェクト (DTO) であり、変更やトランザクションを要求するために使用されるものです。コマンド自体は、コマンドを処理するために必要な情報のみをベースとし、その他の情報は含まれません。

簡略化された CreateOrderCommand クラスの例を次に示します。これは、eShopOnContainers 内の注文マイクロサービスで使用される不変コマンドです。

// DDD and CQRS patterns comment: Note that it is recommended to implement immutable Commands
// In this case, its immutability is achieved by having all the setters as private
// plus only being able to update the data just once, when creating the object through its constructor.
// References on Immutable Commands:
// http://cqrs.nu/Faq
// https://docs.spine3.org/motivation/immutability.html
// http://blog.gauffin.org/2012/06/griffin-container-introducing-command-support/
// https://learn.microsoft.com/dotnet/csharp/programming-guide/classes-and-structs/how-to-implement-a-lightweight-class-with-auto-implemented-properties

[DataContract]
public class CreateOrderCommand
    : IRequest<bool>
{
    [DataMember]
    private readonly List<OrderItemDTO> _orderItems;

    [DataMember]
    public string UserId { get; private set; }

    [DataMember]
    public string UserName { get; private set; }

    [DataMember]
    public string City { get; private set; }

    [DataMember]
    public string Street { get; private set; }

    [DataMember]
    public string State { get; private set; }

    [DataMember]
    public string Country { get; private set; }

    [DataMember]
    public string ZipCode { get; private set; }

    [DataMember]
    public string CardNumber { get; private set; }

    [DataMember]
    public string CardHolderName { get; private set; }

    [DataMember]
    public DateTime CardExpiration { get; private set; }

    [DataMember]
    public string CardSecurityNumber { get; private set; }

    [DataMember]
    public int CardTypeId { get; private set; }

    [DataMember]
    public IEnumerable<OrderItemDTO> OrderItems => _orderItems;

    public CreateOrderCommand()
    {
        _orderItems = new List<OrderItemDTO>();
    }

    public CreateOrderCommand(List<BasketItem> basketItems, string userId, string userName, string city, string street, string state, string country, string zipcode,
        string cardNumber, string cardHolderName, DateTime cardExpiration,
        string cardSecurityNumber, int cardTypeId) : this()
    {
        _orderItems = basketItems.ToOrderItemsDTO().ToList();
        UserId = userId;
        UserName = userName;
        City = city;
        Street = street;
        State = state;
        Country = country;
        ZipCode = zipcode;
        CardNumber = cardNumber;
        CardHolderName = cardHolderName;
        CardExpiration = cardExpiration;
        CardSecurityNumber = cardSecurityNumber;
        CardTypeId = cardTypeId;
        CardExpiration = cardExpiration;
    }


    public class OrderItemDTO
    {
        public int ProductId { get; set; }

        public string ProductName { get; set; }

        public decimal UnitPrice { get; set; }

        public decimal Discount { get; set; }

        public int Units { get; set; }

        public string PictureUrl { get; set; }
    }
}

コマンドクラスには基本的に、ドメインモデルオブジェクトを使用してビジネストランザクションを実行するために必要な、すべてのデータが含まれています。つまり、コマンドは読み取り専用データを含んだデータ構造であり、ビヘイビアーではありません。コマンドの名前は、その目的を示しています。 C# を始めとする多くの言語では、コマンドはクラスとして表されますが、オブジェクト指向における真の意味では、クラスではありません。

もう 1 つの特徴として、コマンドは不変です。なぜなら、コマンドはドメインモデルによって直接処理されるものと想定されているからです。予定された有効期間中に変更する必要がないのです。 C# クラスでは、内部状態を変更する setter やその他のメソッドを使用しないことで、不変性を実現できます。

シリアル化/逆シリアル化プロセスを実行するコマンドを指定するか想定する場合は、プロパティにプライベートセッターと [DataMember] (または [JsonProperty]) 属性が必要であることに注意してください。それ以外の場合、デシリアライザーで、ターゲット先で必要な値を使用してオブジェクトを再構築できなくなります。また、クラスにすべてのプロパティのパラメーターを持つコンストラクターがある場合は、通常のキャメルケース名前付け規則を使用して、コンストラクターに [JsonConstructor] として注釈を付けることができます。ただし、このオプションにはさらに多くのコードが必要です。

たとえば、注文を作成するためのコマンドクラスは通常、データの観点から見れば、作成する注文と同様のものになりますが、通常、同じ属性は必要ありません。たとえば、注文はまだ作成されていないため、CreateOrderCommand に注文 ID はありません。

多くのコマンドクラスは、変更が必要な状態に関するいくつかのフィールドだけを含めればよいので、簡素化することができます。たとえば、注文の状態を「処理中」から「支払済み」(または「発送済み」) 変更するだけの場合は、次のようなシンプルなコマンドで記述できます。

[DataContract]
public class UpdateOrderStatusCommand
    :IRequest<bool>
{
    [DataMember]
    public string Status { get; private set; }

    [DataMember]
    public string OrderId { get; private set; }

    [DataMember]
    public string BuyerIdentityGuid { get; private set; }
}

開発者によっては、UI 要求オブジェクトをコマンド DTO と分離させることもありますが、これは各自の好みで行うものにすぎません。このような分離は、手間がかかる割に付加価値がそれほどなく、オブジェクトはほぼ同様の形状になります。たとえば、eShopOnContainers では、一部のコマンドがクライアント側から直接送られます。

コマンドハンドラークラス

各コマンドについては、特定のコマンドハンドラークラスを実装する必要があります。これによってパターンが機能するようになり、そこでコマンドオブジェクト、ドメインオブジェクト、およびインフラストラクチャリポジトリオブジェクトが使用されます。コマンドハンドラーは、CQRS と DDD の観点から言えば、アプリケーションレイヤーの中心となるものです。ただし、ドメインロジックはすべてドメインクラス内に含める必要があります。つまり、アプリケーションレイヤーのクラスであるコマンドハンドラー内ではなく、集約ルート (ルートエンティティ)、子エンティティ、またはドメインサービス内に含める必要があります。

コマンドハンドラークラスは、前のセクションで説明した単一責任の原則 (SRP) を達成する堅固な手法となります。

コマンドハンドラーはコマンドを受け取り、使用される集約の結果を取得します。結果は、コマンドが正常に実行されるか、例外が返されるかのいずれかになります。例外が返された場合、システム状態は変更されません。

コマンドハンドラーでは通常、次の手順が実行されます。

(メディエーターまたはその他のインフラストラクチャオブジェクトから) コマンドオブジェクト (DTO など) を受け取ります。
コマンドが有効であるかどうかを検証します (メディエーターによって検証されなかった場合)。
現在のコマンドの対象となっている集約ルートインスタンスをインスタンス化します。
集約ルートインスタンスに対してコマンドを実行し、コマンドから必要なデータを取得します。
集約の新しい状態を、関連するデータベースに保持します。この最後の操作が、実際のトランザクションとなります。

通常、コマンドハンドラーは、その集約ルート (ルートエンティティ) によって駆動される単一の集約を操作します。単一コマンドの受信によって複数の集約が影響を受ける場合は、ドメインイベントを使用して複数の集約に状態やアクションを伝達することができます。

ここで重要なポイントは、コマンドの処理中、すべてのドメインロジックはドメインモデル (集約) の内部にあり、単体テスト用に完全にカプセル化されているという点です。コマンドハンドラーは、データベースからドメインモデルを取得する手段として機能し、最後にモデルが変更されたら、その変更を保持するようにインフラストラクチャレイヤー (リポジトリ) に通知します。このアプローチの利点は、プラミングレベル (コマンドハンドラー、Web API、リポジトリなど) に当たるアプリケーションレイヤーやインフラストラクチャレイヤー内のコードを変更することなく、完全にカプセル化された分離型の高機能なビヘイビアードメインモデル内に、ドメインロジックをリファクタリングできるということです。

コマンドハンドラーが複雑になりすぎる (ロジックが多すぎる) 場合には、コードスメルになる可能性があります。内容を見直し、ドメインロジックがある場合はコードをリファクタリングして、そのドメインビヘイビアーをドメインオブジェクト (集約ルートと子エンティティ) のメソッドに移動してください。

次のコードは、この章の最初に示したものと同じ CreateOrderCommandHandler クラスを使用して、コマンドハンドラークラスの例を示したものです。ここでは、Handle メソッドと、ドメインモデルオブジェクトや集約を使用した操作にも焦点を当てています。

public class CreateOrderCommandHandler
        : IRequestHandler<CreateOrderCommand, bool>
{
    private readonly IOrderRepository _orderRepository;
    private readonly IIdentityService _identityService;
    private readonly IMediator _mediator;
    private readonly IOrderingIntegrationEventService _orderingIntegrationEventService;
    private readonly ILogger<CreateOrderCommandHandler> _logger;

    // Using DI to inject infrastructure persistence Repositories
    public CreateOrderCommandHandler(IMediator mediator,
        IOrderingIntegrationEventService orderingIntegrationEventService,
        IOrderRepository orderRepository,
        IIdentityService identityService,
        ILogger<CreateOrderCommandHandler> logger)
    {
        _orderRepository = orderRepository ?? throw new ArgumentNullException(nameof(orderRepository));
        _identityService = identityService ?? throw new ArgumentNullException(nameof(identityService));
        _mediator = mediator ?? throw new ArgumentNullException(nameof(mediator));
        _orderingIntegrationEventService = orderingIntegrationEventService ?? throw new ArgumentNullException(nameof(orderingIntegrationEventService));
        _logger = logger ?? throw new ArgumentNullException(nameof(logger));
    }

    public async Task<bool> Handle(CreateOrderCommand message, CancellationToken cancellationToken)
    {
        // Add Integration event to clean the basket
        var orderStartedIntegrationEvent = new OrderStartedIntegrationEvent(message.UserId);
        await _orderingIntegrationEventService.AddAndSaveEventAsync(orderStartedIntegrationEvent);

        // Add/Update the Buyer AggregateRoot
        // DDD patterns comment: Add child entities and value-objects through the Order Aggregate-Root
        // methods and constructor so validations, invariants and business logic
        // make sure that consistency is preserved across the whole aggregate
        var address = new Address(message.Street, message.City, message.State, message.Country, message.ZipCode);
        var order = new Order(message.UserId, message.UserName, address, message.CardTypeId, message.CardNumber, message.CardSecurityNumber, message.CardHolderName, message.CardExpiration);

        foreach (var item in message.OrderItems)
        {
            order.AddOrderItem(item.ProductId, item.ProductName, item.UnitPrice, item.Discount, item.PictureUrl, item.Units);
        }

        _logger.LogInformation("----- Creating Order - Order: {@Order}", order);

        _orderRepository.Add(order);

        return await _orderRepository.UnitOfWork
            .SaveEntitiesAsync(cancellationToken);
    }
}

次に示すのは、コマンドハンドラーで実行される追加の手順です。

コマンドのデータを使用して、集約ルートのメソッドとビヘイビアーを操作します。
トランザクションの実行中、ドメインオブジェクト内で内部的にイベントを発生させます。ただしこれは、コマンドハンドラーの視点から透過的です。
集約の操作結果が成功である場合は、トランザクションの完了後に、統合イベントを生成します。 (これらは、リポジトリなどのインフラストラクチャクラスによって生成される場合もあります)。

その他の技術情報

Mark Seemann。境界においては、アプリケーションはオブジェクト指向ではない
https://blog.ploeh.dk/2011/05/31/AttheBoundaries,ApplicationsareNotObject-Oriented/
コマンドとイベント
https://cqrs.nu/faq/Command%20and%20Events
コマンドハンドラーの機能
https://cqrs.nu/faq/Command%20Handlers
Jimmy Bogard。ドメインコマンドパターン – ハンドラー
https://jimmybogard.com/domain-command-patterns-handlers/
Jimmy Bogard。ドメインコマンドパターン – 検証
https://jimmybogard.com/domain-command-patterns-validation/

コマンドプロセスパイプライン: コマンドハンドラーをトリガーする方法

次に知るべきことは、コマンドハンドラーを呼び出す方法です。コマンドハンドラーは、関連するそれぞれの ASP.NET Core コントローラーから手動で呼び出すこともできます。ただし、この方法は結合性が高すぎるため、理想的ではありません。

これ以外に次の 2 つの方法があり、これらをお勧めします。

インメモリのメディエーターパターン成果物を通じて呼び出す。
コントローラーとハンドラーの間で非同期メッセージキューを使用して呼び出す。

コマンドパイプラインでメディエーターパターン (インメモリ) を使用する

図 7-25 に示すように、CQRS アプローチではインテリジェントメディエーターを使用します。これはインメモリバスに似たもので、受信されるコマンドや DTO の種類に基づいて、適切なコマンドハンドラーへと処理をスマートにリダイレクトすることができます。コンポーネント間の黒い矢印は、オブジェクト間 (多くの場合、DI を通じて挿入されます) の依存関係と、関連する相互作用を表しています。

Diagram showing a more detailed data flow from client to database.

図 7-25. 単一の CQRS マイクロサービス内のプロセスにおけるメディエーターパターンの使用

上の図は、図 7-24 を拡大したものを示しています。ASP.NET Core コントローラーで MediatR のコマンドパイプラインにコマンドが送信されるため、適切なハンドラーに到達します。

メディエーターパターンの使用がなぜ合理的かというと、エンタープライズアプリケーションでは、処理要求が複雑になる場合があるからです。そのため、ログ記録、検証、監査、セキュリティなどの横断的関心事を、多数追加できるようにすることが重要です。メディエーターパイプライン (「Mediator pattern (メディエーターパターン)」を参照してください) を使用すれば、それらの追加ビヘイビアーや横断的関心事を追加できるようになります。

メディエーターは、このプロセスの「実行方法」をカプセル化するオブジェクトです。メディエーターでは、状態、コマンドハンドラーの呼び出し方法、またはハンドラーに提供するペイロードに基づいて、プロセスの実行を調整できます。メディエーターコンポーネントを使用すると、デコレーター (または MediatR 3 以降のパイプラインビヘイビアー) を適用することで、横断的関心事を一元的かつ透過的に適用することができます。詳細については、「Decorator pattern (デコレーターパターン)」を参照してください。

デコレーターとビヘイビアーは、アスペクト指向プログラミング (AOP) に似ていて、メディエーターコンポーネントによって管理される特定のプロセスパイプラインのみに適用されます。横断的関心事を実装する AOP 内のアスペクトは、コンパイル時に挿入されたアスペクトウィーバーか、オブジェクト呼び出しインターセプションに基づいて適用されます。これらの典型的な AOP アプローチはどちらも、"魔法のように" 動作すると言われます。なぜなら、AOP の動作のしくみを見ることは容易ではないからです。深刻な問題やバグを扱う場合、AOP はデバッグが困難になることがあります。一方、これらのデコレーター/ビヘイビアーは明示的であり、メディエーターのコンテキスト内でのみ適用されるため、デバッグの予測可能性がはるかに高く、デバッグが簡単になります。

たとえば、eShopOnContainers の注文マイクロサービスには、2 つのサンプルビヘイビアーが実装されています (LogBehavior クラスと ValidatorBehavior クラス)。ビヘイビアーの実装については、次のセクションで説明しています。具体的には、eShopOnContainers で MediatR ビヘイビアーがどのように使用されるかを示しています。

コマンドのパイプラインでメッセージキュー (プロセス外) を使用する

もう 1 つの方法は、図 7-26 に示すように、ブローカーやメッセージキューに基づいて非同期メッセージを使用する方法です。この方法は、コマンドハンドラーの直前のメディエーターコンポーネントと組み合わせることもできます。

Diagram showing the dataflow using an HA message queue.

図 7-26. CQRS コマンドでのメッセージキュー (プロセス外およびプロセス間通信) の使用

コマンドのパイプラインは高可用性のメッセージキューで処理し、適切なハンドラーにコマンドを配信することもできます。メッセージキューを使用してコマンドを受信すると、コマンドのパイプラインがさらに複雑になる恐れがあります。多くの場合、外部メッセージキューを通じて接続された 2 つのプロセスにパイプラインを分割する必要が生じるからです。ただし、非同期メッセージングに基づいてスケーラビリティやパフォーマンスを改善する必要がある場合には、この方法を使用することになります。図 7-26 の場合、コントローラーはコマンドメッセージをキューにポストし、そのまま戻ります。その後、コマンドハンドラーは自分のペースでメッセージを処理します。これは、キューの非常に大きな利点です。高度なスケーラビリティが必要な場合、たとえば、在庫などの大量のイングレスデータを扱う場合には、メッセージキューがバッファーの役割を果たすことができるのです。

ただし、非同期であるというメッセージキューの性質上、コマンドの処理が成功したかどうかについて、クライアントアプリケーションとどうやって通信するかを検討する必要があります。原則として、「ファイアアンドフォーゲット」コマンドを使用することはできません。どのようなビジネスアプリケーションでも、コマンドが正常に処理されたかどうかを確認する必要がありますし、少なくとも、検証を経て受け入れられたかどうかを確認する必要があります。

しかし、非同期キューに送信されたコマンドメッセージの検証後にクライアントに応答できるようにすると、トランザクションの実行後に操作の結果を返すインプロセスコマンドプロセスに比べて、システムが複雑になります。キューを使用する場合は、コマンドプロセスの結果を、他の操作結果メッセージを通じて返す必要があるため、システムに追加のコンポーネントやカスタム通信が必要になります。

また、非同期コマンドは一方向のコマンドであり、多くの場合は不要になる可能性があります。これについては、Burtsev Alexey 氏と Greg Young 氏がオンライン会話で交わした興味深いやりとりの中でも説明されています。

[Burtsev Alexey] 私は、非同期コマンド処理や一方向のコマンドメッセージングが、特に理由もなく使用されているコードをよく見かけます (それらのコードでは、長い操作があるわけでもなく、外部の非同期コードを実行しているわけでもなく、アプリケーション境界をまたいでメッセージバスを使用しているわけでもありません)。彼らはなぜ、このようにコードを無駄に複雑化しているのでしょうか。また、私はこれまでブロッキングコマンドハンドラーを使用した CQRS コードを見たことがありませんが、この種のコードはほとんどの場合、問題なく機能します。

[Greg Young] [...] 非同期コマンドは存在しません。これは実際には別のイベントです。あなたが送った要求を私が受け付け、それに同意しない場合にはイベントを発生させる必要があるのであれば、あなたが私に何かを指示していることにはなりません。つまり、それはコマンド (指令) ではありません。何かが実行されたことを、あなたが私に知らせているだけです。これは一見、わずかな違いにも思えますが、大変深い意味があります。

非同期コマンドを使用する場合、エラーを示すための簡単な方法がないので、システムの複雑さが大幅に増します。したがって非同期コマンドは、スケーラビリティ上の要件がある場合や、内部のマイクロサービスとメッセージを通じて通信する特別なケースを除き、推奨されません。これらのケースに該当する場合は、エラー用に個別のレポート/回復システムを設計する必要があります。

eShopOnContainers の初期バージョンには、HTTP 要求から開始され、メディエーターパターンによって駆動される、同期コマンド処理を使用することに決定しました。これにより、プロセスが成功したかどうかを簡単に返すことが可能になっています (CreateOrderCommandHandler 実装を参照)。

いずれにせよ、これについては、アプリケーションやマイクロサービスのビジネス要件に基づいて意思決定を行う必要があります。

メディエーターパターン (MediatR) を使用したコマンドプロセスパイプラインの実装

このガイドでは、サンプル実装として、メディエーターパターンに基づくインプロセスパイプラインを使用してコマンド挿入を駆動し、コマンドを (メモリ内で) 適切なコマンドハンドラーにルーティングする方法を提案します。またこのガイドでは、横断的関心事を分離するためにビヘイビアーを適用することを提案します。

.NET での実装にあたっては、メディエーターを実装するオープンソースライブラリが複数利用可能です。このガイドで使用するライブラリは、 MediatR オープンソースライブラリ (作成者: Jimmy Bogard) ですが、別のアプローチを使用することもできます。 MediatR はコンパクトかつシンプルなライブラリで、デコレーターやビヘイビアーを適用しながら、コマンドなどのインメモリメッセージを処理することができます。

メディエーターパターンを使用すると、結合性を低減し、要求された作業に関係する問題を分離しながら、その作業を実行するハンドラー (この場合はコマンドハンドラー) に自動的に接続することができます。

メディエーターパターンを使用する理由については、このガイドのレビュー時に、Jimmy Bogard からもう 1 点、次のような理由が説明されました。

ここでテストについても触れておいたほうがいいと思います。システムのビヘイビアーに、一貫性ある枠組みを持たせることができます。リクエストイン、レスポンスアウト。このアスペクトは、作成したテストを一貫性を持って動作させるうえで、非常に価値があります。

まずは、メディエーターオブジェクトを実際に使用する、サンプル WebAPI コントローラーから見ていきましょう。メディエーターオブジェクトを今まで使用していなかった場合は、そのコントローラーのすべての依存関係 (ロガーオブジェクトなど) を挿入する必要があります。そのため、コンストラクターが複雑になります。一方、メディエーターオブジェクトを使用している場合は、コントローラーのコンストラクターがかなりシンプルになります。横断的操作ごとに 1 つの依存関係があれば、多数の依存関係を含めなくても、いくつかの依存関係だけで事足ります。次に例を示します。

public class MyMicroserviceController : Controller
{
    public MyMicroserviceController(IMediator mediator,
                                    IMyMicroserviceQueries microserviceQueries)
    {
        // ...
    }
}

メディエーターによって、クリーンでコンパクトな Web API コントローラーコンストラクターが実現しています。また、コントローラーメソッド内では、メディエーターオブジェクトにコマンドを送信するコードが、ほぼ 1 行で記述されています。

[Route("new")]
[HttpPost]
public async Task<IActionResult> ExecuteBusinessOperation([FromBody]RunOpCommand
                                                               runOperationCommand)
{
    var commandResult = await _mediator.SendAsync(runOperationCommand);

    return commandResult ? (IActionResult)Ok() : (IActionResult)BadRequest();
}

べき等コマンドの実装

eShopOnContainers では、上記の例よりもさらに高度なコードで、注文マイクロサービスから CreateOrderCommand オブジェクトが送信されています。ただし、この注文ビジネスプロセスはやや複雑で、(このケースでは) バスケットマイクロサービスから開始されているため、CreateOrderCommand オブジェクトを送信するこのアクションは、先の例のようにクライアントアプリから呼び出されるシンプルな WebAPI コントローラーではなく、UserCheckoutAcceptedIntegrationEventHandler という統合イベントハンドラーから実行されます。

とは言え、MediatR にコマンドを送信するアクションは、次のコードに示すように、非常に似ています。

var createOrderCommand = new CreateOrderCommand(eventMsg.Basket.Items,
                                                eventMsg.UserId, eventMsg.City,
                                                eventMsg.Street, eventMsg.State,
                                                eventMsg.Country, eventMsg.ZipCode,
                                                eventMsg.CardNumber,
                                                eventMsg.CardHolderName,
                                                eventMsg.CardExpiration,
                                                eventMsg.CardSecurityNumber,
                                                eventMsg.CardTypeId);

var requestCreateOrder = new IdentifiedCommand<CreateOrderCommand,bool>(createOrderCommand,
                                                                        eventMsg.RequestId);
result = await _mediator.Send(requestCreateOrder);

ただし、この例ではべき等コマンドも実装しているため、もう少し高度なものになっています。 CreateOrderCommand プロセスはべき等なので、何らかの理由 (再試行など) により同じメッセージがネットワークから重複して送られた場合でも、同じビジネスオーダーは 1 回だけ処理されます。

これは、ビジネスコマンド (この場合は CreateOrderCommand) をラップし、それを汎用の IdentifiedCommand 内に埋め込むことで実装されています。IdentifiedCommand は、ネットワークを通じて送られるメッセージのうち、べき等である必要があるすべてのメッセージの ID によって追跡されます。

次のコードでは、IdentifiedCommand に、DTO と ID のほか、ラップされたビジネスコマンドオブジェクトしか含まれていません。

public class IdentifiedCommand<T, R> : IRequest<R>
    where T : IRequest<R>
{
    public T Command { get; }
    public Guid Id { get; }
    public IdentifiedCommand(T command, Guid id)
    {
        Command = command;
        Id = id;
    }
}

次に、IdentifiedCommand の CommandHandler (IdentifiedCommandHandler.cs) が、メッセージの一部として受け取った ID をチェックし、それがテーブル内に既に存在していないかどうかを確認します。既に存在する場合、そのコマンドは再度処理されることはなく、べき等コマンドとして動作します。そのインフラストラクチャコードは、下記の _requestManager.ExistAsync メソッド呼び出しによって実行されます。

// IdentifiedCommandHandler.cs
public class IdentifiedCommandHandler<T, R> : IRequestHandler<IdentifiedCommand<T, R>, R>
        where T : IRequest<R>
{
    private readonly IMediator _mediator;
    private readonly IRequestManager _requestManager;
    private readonly ILogger<IdentifiedCommandHandler<T, R>> _logger;

    public IdentifiedCommandHandler(
        IMediator mediator,
        IRequestManager requestManager,
        ILogger<IdentifiedCommandHandler<T, R>> logger)
    {
        _mediator = mediator;
        _requestManager = requestManager;
        _logger = logger ?? throw new System.ArgumentNullException(nameof(logger));
    }

    /// <summary>
    /// Creates the result value to return if a previous request was found
    /// </summary>
    /// <returns></returns>
    protected virtual R CreateResultForDuplicateRequest()
    {
        return default(R);
    }

    /// <summary>
    /// This method handles the command. It just ensures that no other request exists with the same ID, and if this is the case
    /// just enqueues the original inner command.
    /// </summary>
    /// <param name="message">IdentifiedCommand which contains both original command & request ID</param>
    /// <returns>Return value of inner command or default value if request same ID was found</returns>
    public async Task<R> Handle(IdentifiedCommand<T, R> message, CancellationToken cancellationToken)
    {
        var alreadyExists = await _requestManager.ExistAsync(message.Id);
        if (alreadyExists)
        {
            return CreateResultForDuplicateRequest();
        }
        else
        {
            await _requestManager.CreateRequestForCommandAsync<T>(message.Id);
            try
            {
                var command = message.Command;
                var commandName = command.GetGenericTypeName();
                var idProperty = string.Empty;
                var commandId = string.Empty;

                switch (command)
                {
                    case CreateOrderCommand createOrderCommand:
                        idProperty = nameof(createOrderCommand.UserId);
                        commandId = createOrderCommand.UserId;
                        break;

                    case CancelOrderCommand cancelOrderCommand:
                        idProperty = nameof(cancelOrderCommand.OrderNumber);
                        commandId = $"{cancelOrderCommand.OrderNumber}";
                        break;

                    case ShipOrderCommand shipOrderCommand:
                        idProperty = nameof(shipOrderCommand.OrderNumber);
                        commandId = $"{shipOrderCommand.OrderNumber}";
                        break;

                    default:
                        idProperty = "Id?";
                        commandId = "n/a";
                        break;
                }

                _logger.LogInformation(
                    "----- Sending command: {CommandName} - {IdProperty}: {CommandId} ({@Command})",
                    commandName,
                    idProperty,
                    commandId,
                    command);

                // Send the embedded business command to mediator so it runs its related CommandHandler
                var result = await _mediator.Send(command, cancellationToken);

                _logger.LogInformation(
                    "----- Command result: {@Result} - {CommandName} - {IdProperty}: {CommandId} ({@Command})",
                    result,
                    commandName,
                    idProperty,
                    commandId,
                    command);

                return result;
            }
            catch
            {
                return default(R);
            }
        }
    }
}

IdentifiedCommand はビジネスコマンドのエンベロープのように動作するので、ビジネスコマンドを処理する必要がある場合 (ID が重複していない場合) には、その内部ビジネスコマンドを受け取り、それを IdentifiedCommandHandler.cs からメディエーターへと再送信します (_mediator.Send(message.Command) を実行している、上記のコードの最後の部分)。

これを行う際には、ビジネスコマンドハンドラー (この場合は、注文データベースに対してトランザクションを実行している CreateOrderCommandHandler) がリンクされ、実行されます。次にコードを示します。

// CreateOrderCommandHandler.cs
public class CreateOrderCommandHandler
        : IRequestHandler<CreateOrderCommand, bool>
{
    private readonly IOrderRepository _orderRepository;
    private readonly IIdentityService _identityService;
    private readonly IMediator _mediator;
    private readonly IOrderingIntegrationEventService _orderingIntegrationEventService;
    private readonly ILogger<CreateOrderCommandHandler> _logger;

    // Using DI to inject infrastructure persistence Repositories
    public CreateOrderCommandHandler(IMediator mediator,
        IOrderingIntegrationEventService orderingIntegrationEventService,
        IOrderRepository orderRepository,
        IIdentityService identityService,
        ILogger<CreateOrderCommandHandler> logger)
    {
        _orderRepository = orderRepository ?? throw new ArgumentNullException(nameof(orderRepository));
        _identityService = identityService ?? throw new ArgumentNullException(nameof(identityService));
        _mediator = mediator ?? throw new ArgumentNullException(nameof(mediator));
        _orderingIntegrationEventService = orderingIntegrationEventService ?? throw new ArgumentNullException(nameof(orderingIntegrationEventService));
        _logger = logger ?? throw new ArgumentNullException(nameof(logger));
    }

    public async Task<bool> Handle(CreateOrderCommand message, CancellationToken cancellationToken)
    {
        // Add Integration event to clean the basket
        var orderStartedIntegrationEvent = new OrderStartedIntegrationEvent(message.UserId);
        await _orderingIntegrationEventService.AddAndSaveEventAsync(orderStartedIntegrationEvent);

        // Add/Update the Buyer AggregateRoot
        // DDD patterns comment: Add child entities and value-objects through the Order Aggregate-Root
        // methods and constructor so validations, invariants and business logic
        // make sure that consistency is preserved across the whole aggregate
        var address = new Address(message.Street, message.City, message.State, message.Country, message.ZipCode);
        var order = new Order(message.UserId, message.UserName, address, message.CardTypeId, message.CardNumber, message.CardSecurityNumber, message.CardHolderName, message.CardExpiration);

        foreach (var item in message.OrderItems)
        {
            order.AddOrderItem(item.ProductId, item.ProductName, item.UnitPrice, item.Discount, item.PictureUrl, item.Units);
        }

        _logger.LogInformation("----- Creating Order - Order: {@Order}", order);

        _orderRepository.Add(order);

        return await _orderRepository.UnitOfWork
            .SaveEntitiesAsync(cancellationToken);
    }
}

MediatR によって使用される型の登録

MediatR にコマンドハンドラークラスを認識させるには、メディエータークラスとコマンドハンドラークラスを IoC コンテナーに登録する必要があります。既定では、MediatR は Autofac を IoC コンテナーとして使用しますが、組み込みの ASP.NET Core IoC コンテナーや、MediatR でサポートされているその他のコンテナーを使用することもできます。

次のコードは、Autofac モジュールを使用している場合に、メディエーターの型とコマンドを登録する方法を示したものです。

public class MediatorModule : Autofac.Module
{
    protected override void Load(ContainerBuilder builder)
    {
        builder.RegisterAssemblyTypes(typeof(IMediator).GetTypeInfo().Assembly)
            .AsImplementedInterfaces();

        // Register all the Command classes (they implement IRequestHandler)
        // in assembly holding the Commands
        builder.RegisterAssemblyTypes(typeof(CreateOrderCommand).GetTypeInfo().Assembly)
                .AsClosedTypesOf(typeof(IRequestHandler<,>));
        // Other types registration
        //...
    }
}

"魔法が起こる" のは、まさにこの部分です。

各コマンドハンドラーでジェネリック IRequestHandler<T> インターフェイスが実装されるため、RegisteredAssemblyTypes メソッドを使用してアセンブリを登録すると、IRequestHandler としてマークされている型もすべて Commands に登録されます。例:

public class CreateOrderCommandHandler
  : IRequestHandler<CreateOrderCommand, bool>
{

これが、コマンドをコマンドハンドラーに関連付けるコードです。ハンドラーは非常にシンプルなクラスですが、RequestHandler<T> から継承されるクラスであり、T はコマンドの型になります。また、MediatR により、正しいペイロード (コマンド) で呼び出されます。

MediatR のビヘイビアーを使用して、コマンドの処理時に横断的関心事を適用する

もう 1 つ重要なことがあります。それは、横断的関心事をメディエーターパイプラインに適用することです。 Autofac 登録モジュールコードの末尾を見ると、ビヘイビアー型 (カスタム LoggingBehavior クラスと ValidatorBehavior クラス) がどのように登録されるかがわかります。ただし、その他のカスタムビヘイビアーを追加することもできます。

public class MediatorModule : Autofac.Module
{
    protected override void Load(ContainerBuilder builder)
    {
        builder.RegisterAssemblyTypes(typeof(IMediator).GetTypeInfo().Assembly)
            .AsImplementedInterfaces();

        // Register all the Command classes (they implement IRequestHandler)
        // in assembly holding the Commands
        builder.RegisterAssemblyTypes(
                              typeof(CreateOrderCommand).GetTypeInfo().Assembly).
                                   AsClosedTypesOf(typeof(IRequestHandler<,>));
        // Other types registration
        //...
        builder.RegisterGeneric(typeof(LoggingBehavior<,>)).
                                                   As(typeof(IPipelineBehavior<,>));
        builder.RegisterGeneric(typeof(ValidatorBehavior<,>)).
                                                   As(typeof(IPipelineBehavior<,>));
    }
}

この LoggingBehavior クラスは、次のコードとして実装することができます。これにより、実行されるコマンドハンドラーに関する情報と、それが成功したかどうかどうかが記録されます。

public class LoggingBehavior<TRequest, TResponse>
         : IPipelineBehavior<TRequest, TResponse>
{
    private readonly ILogger<LoggingBehavior<TRequest, TResponse>> _logger;
    public LoggingBehavior(ILogger<LoggingBehavior<TRequest, TResponse>> logger) =>
                                                                  _logger = logger;

    public async Task<TResponse> Handle(TRequest request,
                                        RequestHandlerDelegate<TResponse> next)
    {
        _logger.LogInformation($"Handling {typeof(TRequest).Name}");
        var response = await next();
        _logger.LogInformation($"Handled {typeof(TResponse).Name}");
        return response;
    }
}

このビヘイビアークラスを実装し、それをパイプラインで登録することで (上記の MediatorModule)、MediatR を通じて処理されたすべてのコマンドが、実行に関するロギング情報になります。

eShopOnContainers 注文マイクロサービスでは、基本検証用に 2 つ目のビヘイビアーも適用されます。FluentValidation ライブラリに依存する ValidatorBehavior クラスです。次にコードを示します。

public class ValidatorBehavior<TRequest, TResponse>
         : IPipelineBehavior<TRequest, TResponse>
{
    private readonly IValidator<TRequest>[] _validators;
    public ValidatorBehavior(IValidator<TRequest>[] validators) =>
                                                         _validators = validators;

    public async Task<TResponse> Handle(TRequest request,
                                        RequestHandlerDelegate<TResponse> next)
    {
        var failures = _validators
            .Select(v => v.Validate(request))
            .SelectMany(result => result.Errors)
            .Where(error => error != null)
            .ToList();

        if (failures.Any())
        {
            throw new OrderingDomainException(
                $"Command Validation Errors for type {typeof(TRequest).Name}",
                        new ValidationException("Validation exception", failures));
        }

        var response = await next();
        return response;
    }
}

ここでは、検証に失敗した場合にビヘイビアーによって例外が生成されますが、結果オブジェクトを返せる場合もあります。成功であればコマンド結果が含まれ、失敗であれば検証メッセージが含まれます。おそらくは、より簡単にユーザーに検証結果を示すことができます。

その後、FluentValidation ライブラリに基づいて、次のコードに示すように、CreateOrderCommand によって渡されるデータの検証を作成しました。

public class CreateOrderCommandValidator : AbstractValidator<CreateOrderCommand>
{
    public CreateOrderCommandValidator()
    {
        RuleFor(command => command.City).NotEmpty();
        RuleFor(command => command.Street).NotEmpty();
        RuleFor(command => command.State).NotEmpty();
        RuleFor(command => command.Country).NotEmpty();
        RuleFor(command => command.ZipCode).NotEmpty();
        RuleFor(command => command.CardNumber).NotEmpty().Length(12, 19);
        RuleFor(command => command.CardHolderName).NotEmpty();
        RuleFor(command => command.CardExpiration).NotEmpty().Must(BeValidExpirationDate).WithMessage("Please specify a valid card expiration date");
        RuleFor(command => command.CardSecurityNumber).NotEmpty().Length(3);
        RuleFor(command => command.CardTypeId).NotEmpty();
        RuleFor(command => command.OrderItems).Must(ContainOrderItems).WithMessage("No order items found");
    }

    private bool BeValidExpirationDate(DateTime dateTime)
    {
        return dateTime >= DateTime.UtcNow;
    }

    private bool ContainOrderItems(IEnumerable<OrderItemDTO> orderItems)
    {
        return orderItems.Any();
    }
}

追加の検証を作成することもできます。これは、コマンド検証を実装するための非常にクリーンで簡潔な方法です。

同様の方法で、コマンドの処理時にそれらに適用したい追加のアスペクトや横断的関心事に対する、その他のビヘイビアーを実装することもできます。

その他の技術情報

Fluent 検証

Jeremy Skinner。 FluentValidation. GitHub リポジトリ。
https://github.com/JeremySkinner/FluentValidation

前へ次へ

Web API を使用してマイクロサービスアプリケーションレイヤーを実装する

依存関係挿入を使用し、アプリケーションレイヤーにインフラストラクチャオブジェクトを挿入する

依存関係実装の型とインターフェイス (または抽象化) の登録

ASP.NET Core で提供される組み込み IoC コンテナーの使用

自動登録用の Scrutor ライブラリの使用

その他の技術情報

Autofac を IoC コンテナーとして使用する

その他の技術情報

コマンドおよびコマンドハンドラーパターンの実装

コマンドクラス

コマンドハンドラークラス

その他の技術情報

コマンドプロセスパイプライン: コマンドハンドラーをトリガーする方法

コマンドパイプラインでメディエーターパターン (インメモリ) を使用する

コマンドのパイプラインでメッセージキュー (プロセス外) を使用する

メディエーターパターン (MediatR) を使用したコマンドプロセスパイプラインの実装

べき等コマンドの実装

MediatR によって使用される型の登録

MediatR のビヘイビアーを使用して、コマンドの処理時に横断的関心事を適用する

その他の技術情報

メディエーターパターン

デコレーターパターン

MediatR (Jimmy Bogard)

Fluent 検証

フィードバック

その他のリソース

Web API を使用してマイクロサービス アプリケーション レイヤーを実装する

依存関係挿入を使用し、アプリケーション レイヤーにインフラストラクチャ オブジェクトを挿入する

依存関係実装の型とインターフェイス (または抽象化) の登録

ASP.NET Core で提供される組み込み IoC コンテナーの使用

自動登録用の Scrutor ライブラリの使用

その他の技術情報

Autofac を IoC コンテナーとして使用する

その他の技術情報

コマンドおよびコマンド ハンドラー パターンの実装

コマンド クラス

コマンド ハンドラー クラス

その他の技術情報

コマンド プロセス パイプライン: コマンド ハンドラーをトリガーする方法

コマンド パイプラインでメディエーター パターン (インメモリ) を使用する

コマンドのパイプラインでメッセージ キュー (プロセス外) を使用する

メディエーター パターン (MediatR) を使用したコマンド プロセス パイプラインの実装

べき等コマンドの実装

MediatR によって使用される型の登録

MediatR のビヘイビアーを使用して、コマンドの処理時に横断的関心事を適用する

その他の技術情報

メディエーター パターン

デコレーター パターン

MediatR (Jimmy Bogard)

Fluent 検証

フィードバック

その他のリソース

Web API を使用してマイクロサービスアプリケーションレイヤーを実装する

依存関係挿入を使用し、アプリケーションレイヤーにインフラストラクチャオブジェクトを挿入する

コマンドおよびコマンドハンドラーパターンの実装

コマンドクラス

コマンドハンドラークラス

コマンドプロセスパイプライン: コマンドハンドラーをトリガーする方法

コマンドパイプラインでメディエーターパターン (インメモリ) を使用する

コマンドのパイプラインでメッセージキュー (プロセス外) を使用する

メディエーターパターン (MediatR) を使用したコマンドプロセスパイプラインの実装

メディエーターパターン

デコレーターパターン