CQRS +イベントソーシングの概要：パート1.基本

CQRSについて初めて聞いたのは、新しい仕事を得たときです。 私が今日まで働いている会社は、CQRS、Event Sourcing、およびMongoDBが、私が取り組むプロジェクトのデータベースとして使用されているとすぐに言われました。 これらすべてから、MongoDBについてのみ聞いた。 CQRSを掘り下げてみると、このアプローチの複雑さをすぐには理解できませんでしたが、何らかの理由で、データ相互作用モデルを読み取りと書き込みの2つに分割するアイデアが好きでした。 おそらくそれが「職務の分離」プログラミングパラダイムと共鳴したのは、おそらくDDDの精神に非常に忠実だったからでしょう。

一般的に、多くの人がデザインパターンとしてCQRSについて語っています。 私の意見では、それは単に「設計パターン」と呼ばれるには、アプリケーションの全体的なアーキテクチャに影響を与えるため、原則またはアプローチと呼ぶことを好みます。 CQRSを使用すると、アプリケーションのほぼすべての隅々まで浸透します。

すぐに明確にしたいのは、CQRS + Event Sourcingの束だけで作業したことです。CQRSだけを試したことはありません。EventSourcingなしでは多くの利点が失われるように思えるからです。 企業のParalect.DomainをCQRSフレームワークとして使用します。 彼は他の人よりも悪い人よりも優れている。 いずれにしても、私はあなたが残りに精通することを勧めます。 ここでは、いくつかの.NETフレームワークについてのみ言及します。 最も人気のあるのは、 NCQRS 、 Lokad CQRS 、 SimpleCQRSです。 また、膨大な数の異なるデータベースをサポートするJonathan Oliver Event Storeを見ることができます。

CQRSから始めましょう

CQRSとは何ですか？
CQRSはCommand Query Responsibility Segregationの略です。 これは、グレッグヤングから最初に聞いたデザインパターンです。 これは、さまざまなモデルを使用して情報を更新および読み取ることができるという単純な概念に基づいています。 ただし、この単純な概念は、情報システムの設計に重大な結果をもたらします。 （c）マーティン・ファウラー

網羅的な定義とは言いませんが、今度はファウラーが何を念頭に置いていたかを説明しようとします。
これまでのところ、事実上すべての人がCRUDリポジトリと同様にデータモデルを操作するような状況が発生しました。 CQRSは代替アプローチを提供しますが、データモデルだけでなく影響を与えます。 CQRSを使用する場合、これはアプリケーションのアーキテクチャに大きく影響します。

これは私がCQRSフローチャートを描いた方法です


最初に目を引くのは、読み取り用（クエリ）と書き込み用（コマンド）の2つのデータモデルが既にあることです。 通常、これは2つのデータベースも持っていることを意味します。 そして、CQRS + Event Sourcingを使用しているため、書き込みベース（書き込みモデル）はすべてのユーザーアクションのログのようなイベントストアです（実際、すべてではなく、ビジネスモデルの観点から重要なアクションのみ）読み取りベースの構築に影響します）。 また、読み取りベースは通常、ユーザーに表示する必要があるデータの非正規化リポジトリです。 読み取りベースが非正規化されていると言ったのはなぜですか？ もちろん、任意のデータ構造を読み取りモデルとして使用できますが、CQRS + Event Sourcingを使用する場合は、いつでも完全に再構築できるため、読み取りベースの正規化にあまり煩わすべきではないと思います。 特に、リレーショナルデータベースを使用せずにNoSQLを使用する場合は、これは大きなプラスになります。
書き込みベースは通常、イベントの1つのコレクションです。 つまり、リレーショナルデータベースを使用しても意味がありません。

イベントソーシング

イベントソーシングの背後にある考え方は、アプリケーションの状態をデータベースに変更するすべてのイベントを記録することです。 したがって、エンティティの状態ではなく、エンティティに関連するすべてのイベントを保存することがわかります。 しかし、私たちは状態を正確に操作することに慣れており、データベースに保存されており、いつでも見ることができます。
イベントソーシングの場合、エンティティの状態も操作します。 ただし、通常のモデルとは異なり、この状態は保存せず、呼び出すたびに再生します。



データベースからユニットを生成するコードを見ると、従来のアプローチとの違いに気付かないかもしれません。

var user = Repository.Get<UserAR>(userId); 

実際、リポジトリはデータベースからUserARアグリゲートの準備完了状態を取得せず（AR = Aggregate Root）、データベースからこのユーザーに関連付けられているすべてのイベントを選択し、アグリゲートのOn（）メソッドに渡すためにそれらを再生します。

たとえば、UserAR集計クラスには、ユーザー状態でIDを復元するために次のメソッドが必要です。

 protected void On(User_CreatedEvent created) { _id = created.UserId; } 

ユニットの状態全体から、ユーザーの_idのみが必要なので、パスワード、名前などの状態を復元できます。 ただし、これらのフィールドは、それぞれUser_CreatedEventだけでなく、他のイベントによって変更することもできます。すべてを処理する必要があります。 すべてのイベントは順番に再生されるため、この状態を変更するすべてのイベントのOn（）ハンドラーを記述していない限り、常に集約の最新の現在の状態で作業することを確信しています。

CQRS + Event Sourcingの動作方法をユーザーに作成する例を見てみましょう。

チームの作成と送信

最初にやることは、チームを結成して送ることです。 簡単にするために、ユーザー作成コマンドに必要なフィールドのみを設定し、次のようにします。

 public class User_CreateCommand: Command { public string UserId { get; set; } public string Password { get; set; } public string Email { get; set; } } 

チームのクラス名を混同しないでください。一般的に受け入れられているガイドラインに対応していませんが、所属するユニットと実行されているアクションをすぐに理解できます。

 var command = new User_CreateCommand { UserId = “1”, Password = “password”, Email = “test@test.com”, }; command.Metadata.UserId = command.UserId; _commandService.Send(command); 

次に、このコマンドのハンドラーが必要です。 コマンドハンドラは、必要な集約のIDを渡す必要があります。このIDによって、リポジトリから集約を受け取ります。 リポジトリは次のように集約オブジェクトを構築します。この集約に関連するすべてのイベントをデータベースから取得し、新しい空の集約オブジェクトを作成し、集約オブジェクトで受信したイベントを順番に再生します。
ただし、作成チームがあるため、データベースから調達するものはありません。つまり、自分で集計を作成し、それにコマンドメタデータを渡します。

 public class User_CreateCommandHandler: CommandHandler<User_CreateCommand> { public override void Handle(User_CreateCommand message) { var ar = new UserAR(message.UserId, message.Email, message.Password, message.Metadata); Repository.Save(ar); } } 

ユニット設計者がどのように見えるか見てみましょう。

 public UserAR(string userId, string email, string password, ICommandMetadata metadata): this() { _id = userId; SetCommandMetadata(metadata); Apply(new User_CreatedEvent { UserId = userId, Password = password, Email = email }); } 

また、アグリゲートにはパラメーターのないコンストラクターが必要です。これは、リポジトリがアグリゲートの状態を再現するときに、最初にパスを使用してインスタンスを作成し、次にイベントを投影メソッドに渡す必要があるためです（ Onメソッド（User_CreatedEvent created）は投影メソッドの1つです）。
投影について少し説明します。 プロジェクションは、その実装に関連するイベントストアからのイベントに基づいて、実装の状態を再現したものです。 ユーザーの例では、これらはすべてこの特定のユーザーのイベントです。 そして、Applyメソッドを介して保存されるすべての同じイベントである集約は、その状態の再生中に処理できます。 フレームワークでは、このためにOnメソッド（/ * EventType arg * /）を記述するだけで十分です。ここで、EventTypeは処理するイベントのタイプです。

集約のApplyメソッドは、すべてのハンドラーへのイベントの送信をトリガーします。 実際、イベントは、アグリゲートがリポジトリに保存されたときにのみディスパッチされ、Applyは単にイベントをアグリゲートの内部リストに追加します。
ユーザー自身の読み取りベースに書き込むユーザーを作成するためのイベントハンドラー（！）を次に示します。

 public void Handle(User_CreatedEvent message) { var doc = new UserDocument { Id = message.UserId, Email = message.Email, Password = message.Password }; _users.Save(doc); } 

イベントには複数のハンドラーを含めることができます。 このアーキテクチャは、データが大幅に非正規化された場合にデータの整合性を維持するのに役立ちます。 ユーザーの総数を頻繁に表示する必要があるとします。 しかし、それらの数が多すぎるため、データベースに対するカウント操作は非常に高価です。 その後、既に統計を参照する別のイベントハンドラを作成し、ユーザーを追加するたびに、合計ユーザーカウンターを1ずつ増やします。そして、カウンターを更新せずにユーザーを作成しないようにします。 CQRSを使用していなかったが、通常のORMを使用していた場合、使用するために追加および削除するすべての場所をたどって、カウンターが更新されるようにする必要があります。
また、イベントソーシングを使用すると、さらにメリットがあります。 EventHandlerでミスをしたり、必要な場所でイベントを処理しなかった場合でも、正しいビジネスロジックで読み取りデータベースをリダイレクトするだけで簡単に修正できます。

作成で理解することができます。 集計変更とチーム検証はどのように行われますか？ パスワード変更の例を考えてみましょう。
他の場所では一般的に違いはそれほど大きくないため、コマンドハンドラとChangePassword（）集約メソッドのみを提供します。

コマンドハンドラー

 public class User_ChangePasswordCommandHandler: IMessageHandler<User_ChangePasswordCommand> { //   public void Handle(User_ChangePasswordCommand message) { //     var user = _repository.GetById<UserAR>(message.UserId); //   user.SetCommandMetadata(message.Metadata); //   user.ChangePassword(message.OldPassword, message.NewPassword); //   _repository.Save(user); } } 

集約ルート

 public class UserAR : BaseAR { //... public void ChangePassword(string oldPassword, string newPassword) { //      ,   if (_password != oldPassword) { throw new AuthenticationException(); } //    -   Apply(new User_Password_ChangedEvent { UserId = _id, NewPassword = newPassword, OldPassword = oldPassword }); } //       protected void On(User_Password_ChangedEvent passwordChanged) { _password = passwordChanged.NewPassword; } //           protected void On(User_CreatedEvent created) { _id = created.UserId; _password = created.Password; } } } 

無効なイベントをApply（）メソッドに渡すことはお勧めできません。 もちろん、イベントハンドラで後で処理することもできますが、重要ではない場合はイベントストアを詰まらせるだけなので、まったく保存しない方が良いでしょう。
パスワードの変更の場合、もちろん失敗したパスワードの変更に関する統計を収集しない限り、このイベントを保存することは意味がありません。 そして、この場合でも、このイベントが書き込みモデルで自分にとって役に立たないのか、それともテンポストレージに書き込むのが理にかなっているかを慎重に検討する必要があります。 イベント検証のビジネスロジックが変更される可能性があると思われる場合は、保存します。

実際、この記事で説明したいことはこれだけです。 もちろん、CQRS +イベントソーシングのすべての側面と可能性を明らかにするわけではありません。これについては今後の記事で説明する予定です。 このアプローチを使用する際に発生する問題も背後に残っています。 そして、それについても話します。
質問がある場合は、コメントで質問してください。 喜んでお答えします。 また、次の記事に何か提案があれば-本当に聞きたいです。

ソース

ASP.NET MVCの完全に機能する例はこちらです。
データベースは存在せず、すべてがメモリに保存されます。 必要に応じて、ねじ込むだけで十分です。 また、イベントを保存するためのMongoDBのイベントストアの既製の実装もすぐに使用できます。
Global.asaxファイルに組み込むには、InMemoryTransitionRepositoryをMongoTransitionRepositoryに置き換えるだけで十分です。
読み取りモデルとして、静的コレクションがあるため、再起動するたびにデータが破壊されます。

次は？

このトピックに関する記事についていくつかのアイデアがあります。 もっと提案する。 最も興味深いものを言います。

• スナップショットとは何ですか、なぜ必要なのか、詳細と実装オプション。
• イベントストア。
• データベースの再生成。 機会。 パフォーマンスの問題。 並列化。 パッチ。
• 集約ルートによって設計されています。
• 実際のプロジェクトへの適用。 1つのプロジェクトは外部委託され、2番目のプロジェクトは私のスタートアップです。
• サードパーティサービスの統合の機能。