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