プロジェクトで使用するためのCQRSの調査の一環として、Axon Frameworkに出くわしましたが、実際にCQRSを使用した経験がある人はいないかと思いました。明確にするために、アーキテクチャパターンとしてのCQRSではなく、フレームワークについて質問しています。
私のプロジェクトでは、Axon自身の要件にうまく適合するSpringとSpring Integrationをすでに使用していますが、それに多くの時間を割く前に、誰かが直接の経験を持っているかどうかを知りたいと思います。特に、ドキュメントからすぐには明らかにならない可能性のある落とし穴に興味があります。
フレームワークはイベントソーシングに大きく依存しています。つまり、すべての状態変更がイベントとしてデータストアに書き込まれます。「」
これは完全に真実ではなく、イベントソーシングに大きく依存していません。このフレームワークに集計を格納するための実装の1つは、イベントソーシングを使用しますが、標準のリレーショナルモデルを使用するために提供されているクラスも簡単に使用できます。
イベントソーシングの方が優れています。
したがって、すべてのデータの履歴参照があります。これは素晴らしいことですが、特にシステムの「強力な監査可能性」で顧客を販売した場合は、本番環境に移行した後にドメインを変更することは非常に困難な提案になります。
現在の状態のみを格納する標準のリレーショナルモデルでは、それほど簡単ではないと思います。
フレームワークは、データを非正規化することを推奨し、アプリケーションのビューごとにテーブルを作成することを提案する人もいます。これにより、特に元の開発者がいなくなった場合、アプリケーションの保守が非常に困難になります。」
これはフレームワークとは関係ありませんが、使用中のアーキテクチャパターン（CQRS）とは関係ありません。申し訳ありませんが、非正規化機能/ビューを1つ持つことは、単純なオブジェクトのままであるため、良い考えです。
SQLの要求/挿入も簡単なので、メンテナンスも簡単です。したがって、この議論はそれほど強力ではありません。どこでも内部結合と複雑なSQLクエリを備えた1000テーブルモデルを使用するビューはどうですか？
繰り返しになりますが、CQRSは、基本的に、ビューデータがビューに対応するテーブルからの単なるSELECT*であるために役立ちます。
何らかの理由でイベントハンドラーの1つを間違えた場合、唯一のオプションはイベントログを「再生」することです。これは、データのサイズによっては非常に長い時間がかかる場合があります。ただし、このためのツールは存在しません。
現在、イベントを再生するためのツールが不足しており、これには長い時間がかかる可能性があるという点に同意します。ただし、理論的には、イベントの一部のみを再生でき、イベントストアのすべてのコンテンツを再生できるわけではありません。
再生には副作用がある可能性があるため、>開発者はそれを行うことを恐れるようになります
イベントの再生には副作用があります->それは真実ではありません。私にとって副作用とは、システムの状態を変更することを意味します。イベントソースのCQRSアプリケーションでは、状態はイベントストアに格納されます。イベントを再生しても、イベントストアは変更されません。はい、モデルのクエリ側に副作用が発生する可能性があります。ただし、間違いを修正してイベントをもう一度再生できるため、間違いを犯してもかまいません。
開発者がこのフレームワークを使用して混乱するのは非常に簡単です。ドメインオブジェクトへの変更をイベントに保存しない場合は、次にイベントを再生するときに、サプライズが発生します。
アーキテクチャやコンセプトなどを誤用して誤解している場合は、同意します。しかし、おそらく問題はここでのフレームワークではありません。
デルタを保存する必要がありますか？絶対値？開発者を監視しないと、>両方になってしまい、失敗することになります。
すべてのシステムについて、フレームワーク自体とは直接関係がないと言えます。これは、「誰かがhashCodeの不適切な実装をコーディングし、メソッドと同等である場合、すべてを台無しにする可能性があるため、Javaはくだらない」と言っているようなものです。
コメントの最後の部分では、Springフレームワークを使用したhelloWorldのようなサンプルをすでに見ました。もちろん、簡単な例ではまったく役に立ちません。
コメントでは、概念（CQRS + EventSourcing）とフレームワークを区別するように注意してください。違いを作ってください。
プロジェクトにCQRSを使用したいとおっしゃっていたので（そして、JVMがターゲットプラットフォームであると思います）、AxonFrameworkが優れた選択肢だと思います。
私はその上にかなり複雑な取引プラットフォームを構築しました（いいえ、取引サンプルは複雑ではありません）、フレームワークの明らかな欠陥は見ていません。
私はEventSourcingを使用しているので、テストフィクスチャにより、BDDスタイルの「与えられたとき、いつ、そして」テストを非常に簡単に作成できました。これにより、アグリゲートをブラックボックスとして扱い、特定のコマンドを入力したときに正しいイベントのセットが出力されることを確認することに集中できます。
落とし穴について：飛び込む前に、次のことを確認してください
いくつかの非軸索固有のポイント：
イベントからビューストアを再構築できることはEventSourcingの概念であり、Axon専用のものではありませんが、集計タイプ、集計ID、または特定のイベントからすべてのイベントを送信するサービスを作成するのは非常に簡単です。イベントタイプ。
プロジェクトが開始されてから1年後に新しいレポートコンポーネントを構築し、プロジェクトの開始時以降のデータに関するレポートを即座に取得できることは素晴らしいことです。
私は大手銀行向けに開発された複雑なプロジェクトで1年以上AxonFrameworkを使用しています。
要件は厳しく、顧客の期待は高く、リリース期間は狭かった。
私がAxonFrameworkを選択したのは、プロジェクトの開始時に、Javaで利用可能なCQRSの最も完全で文書化された実装であり、適切に設計され、統合、テスト、および拡張が容易であったためです。
1年以上経った今でも、これらの考慮事項は有効で最新のものだと思います。
別の考慮事項が私の選択を導きました。このような困難なプロジェクトへの取り組みが、私やチームの他のメンバーのトレーニングの機会になることを望んでいました。
AxonFrameworkバージョン1.0で開発を開始し、新しいバージョンがリリースされたときにバージョン1.4に移行しました。
CQRSとAxonFrameworkによって提供された実装に関する私たちのチームの経験は絶対にポジティブでした。
それは私たちを導き、あなたが安心できるようにする各機能を開発するための一貫した均一な方法を私たちに提供しました。
これがなければ、アプリケーションの一部の機能の開発ははるかに複雑になります。私は主に、処理する必要のあるさまざまな長期実行プロセスと関連する補償ロジックについて言及していますが、イベント駆動型アーキテクチャにうまく適合し、切り離された、あちこちで必要とされている多くのビジネスロジックの部分についても言及しています。 CQRSによって促進されます。
書き込みモデルでは保守的であることが選択されたため、イベントソースの永続性ではなく、JPAベースの永続性を選択しました。
クエリモデルはビューで構成されています。必要に応じて中間ビューを使用して、各ビューに1つのページから必要なすべてのデータが含まれるようにしました。
とにかく、イベントソーシングを適用しながら書き込みモデルを開発したので、イベントのみを介して集計の状態を変更します。顧客が非常に複雑なアグリゲートのクローン作成機能を要求したとき、それは（uuidが変換された）ソースイベントを新しいインスタンスに再生するだけの問題でした-この場合の欠点は、イベントのアップキャストでした（ただし、この機能は差し迫った2.0バージョンで大幅に改善されました）。
開発中の各プロジェクトと同様に、主にコードだけでなく、アプリケーションサーバー、IoCコンテナー、キャッシュ、ワークフローエンジンなど、成熟して安定していると思われるコンポーネントにも多くのバグが見つかりました。大規模なJ2EEアプリケーションで簡単に見つけることができるライブラリ。
他の人間の製品であるAxonFrameworkもバグの影響を受けませんでしたが、驚くべきことに、このような若くてニッチなプロジェクトでは、バグは少なく、重要ではなく、新しいリリースですぐに解決されました。
メーリングリストで著者が提供してくれた親切で迅速なサポートは、もう1つの貴重な機能であり、困ったときに大いに役立ちました。
このアプリケーションは1年前に本番環境でリリースされ、現在も維持されており、新機能の開発が活発に行われています。
顧客は満足しており、さらに多くを求めています。
AxonFrameworkをいつ使用するかは、CQRSをいつ使用するかによって決まります。回答については、公式ドキュメントに戻る価値があります： http ://www.axonframework.org/docs/1.4/introduction.html#d4e51
私たちの場合、間違いなくそれだけの価値がありました。
OPは、CQRSではなくAxonフレームワークに関連する落とし穴について具体的に質問します。AxonはEricEvansによる有名な本のかなり忠実な実装として始まったので、これは質問に答えるのを難しくします
主な利点は、缶に書かれていることを正確に実行することです。CQRSベースの設計の難しい部分（集約、サガ、イベントソーシング、コマンドハンドラー、イベントハンドラー、BASE整合性など）を処理します。実践すると、応答性が高く、水平方向にスケーラブルなアプリケーションになります。イベントソーシングで使用する場合、データは完全に監査可能であり、少なくとも理論的には、任意の時点でのアプリケーションの状態を判断できます。これを行うためのツールは提供されていません。あなたはあなた自身を転がさなければならないでしょう。
フレームワークの主な開発者は、Javaでの高性能でスケーラブルなコンピューティングに関して、非常に親しみやすく、非常に知識が豊富です。彼は、メーリングリストのすべての質問に数時間以内に答える傾向があります。これは利点であると同時に大きな落とし穴でもあります。現時点（2014年初頭）では、Axonフレームワークは1人の人間に大きく依存しています。私が言及したい残りの落とし穴は、おそらくCQRSやAxonよりもイベントソーシングの結果です（2018年現在、フレームワークはAxoniq社によってサポートされています）
データモデルは、事前に慎重に設計してください。追加するのは簡単ですが、データモデルに基本的な変更を加えることは非常に難しい場合があります。データモデルに根本的な間違いを犯した場合、アプリケーションのパフォーマンスが低下したり、まったく機能しなくなったりする可能性があります。たとえば、1つの長寿命の集計ルートが上部にあるツリー型のデータモデルを選択した場合、この集計は時間の経過とともにイベントが増えるにつれて非常に大きくなる可能性があり、読み込みと保存に長い時間がかかる可能性があります。アグリゲートのインスタンスがRAMに収まらなくなるまでこれが続くとどうなるかわかりませんが、悪い可能性があると思います。そのようにしないでください。
もう1つの落とし穴（イベントソーシング関連）は、何度も改訂した後、コードが今日何をしているのかだけでなく、それが何をしているのかを覚えておく必要があるため、集計の状態について推論することがますます難しくなる可能性があることです。過去にやった。これにより、イベントストア（の一部）を再生してビューテーブルを再構築することは簡単な作業ではありません。
データエラーの修正は、「従来の」設計よりも難しい場合があります。多くの場合、単純なSQLステートメントではなく、アプリケーションの状態を変更するコマンドを作成する必要があります。データのエラーの原因がイベントハンドラーの障害である場合は、通常、バグを修正し、スナップショットをクリアして、集計のイベントを再生させることができます。あなたのバグが偽のイベントを適用する原因となった場合、それは私が修正するのにはるかに多くの問題を引き起こす可能性があります。障害のあるイベントはイベントストアに残ります。データを正しい状態に復元するために新しいイベントを適用するか、コードを変更してそれらの動作を無視または修正する必要がある場合があります。
フレームワーク自体は十分に適切に記述されていますが、実際のプロジェクトでフレームワークを使用することは悪夢にほかなりません。このフレームワークimoの選択は、このプロジェクトの失敗の主な要因でした。
フレームワークはイベントソーシングに大きく依存しています。つまり、すべての状態変更がイベントとしてデータストアに書き込まれます。したがって、すべてのデータの履歴参照があります。これは素晴らしいことですが、特にシステムの「強力な監査可能性」で顧客を販売した場合、本番環境に移行した後にドメインを変更することは非常に困難な提案になります。
運用担当者にデータベースにアドホックな変更を加えることはできません
フレームワークは、データを非正規化することを推奨し、アプリケーションのビューごとにテーブルを作成することを提案する人もいます。これにより、特に元の開発者がいなくなった場合、アプリケーションの保守が非常に困難になります。
何らかの理由でイベントハンドラーの1つを間違えた場合、唯一のオプションはイベントログを「再生」することです。これは、データのサイズによっては非常に長い時間がかかる場合があります。ただし、このためのツールは存在しません。再生には副作用がある可能性があるため、開発者はそれを行うことを恐れるようになります
開発者がこのフレームワークを使用して混乱するのは非常に簡単です。ドメインオブジェクトへの変更がイベントに保存されていない場合は、次にイベントを再生するときに驚きます。デルタを保存する必要がありますか？絶対値？開発者を監視しないと、両方になってしまい、失敗します。
このフレームワークの採用は事実上ないので、答えをグーグルで検索しても何の役にも立ちません。
フレームワークはまだ配布をサポートしていませんが、それを念頭に置いて作成されており、APIを使用するのは面倒です。イベントの発生はデフォルトでは非同期であり、コマンドの実行で例外が発生したかどうかを確認する場合、たとえば重複ユーザー名例外の場合は、futureであるコマンドハンドラーにリスナーを渡す必要があります。その後、futureが発生するのを待ちます。結果が入り、チェックされた例外、interuptedexceptionなどを処理すると、将来からスローされた例外を取得できます。もちろん、コマンドが発生させる可能性のある例外は、APIからは明らかではありません。チェックされた例外の目的を無効にする
いくつかのサンプルアプリをチェックしてください。名簿アプリケーションを作成するには、どういうわけか作業単位のリスナーが必要ですか？私の良さ...
私は現在、オンラインカジノプラットフォームに取り組んでいるチームと一緒に、今年の夏に私たちのブランドCasumoを立ち上げています。ドメインとプラットフォームはAxonFrameworkを使用して構築されており、これまでのところしっかりと役立っています。
コマンド処理、イベントルーティング、イベントソーシング、スナップショットなどに必要なすべてのインフラストラクチャを構築する必要がないため、多くの時間が節約され、APIは非常に便利です。これまでにフレームワークで見つかった1つのバグは、12時間後のリリースで修正されました。Allardは常に新しい機能に関する提案を迅速に行い、フレームワークを活用してニーズを満たす方法について話し合っています。