0

私の職場では、ソフトウェア プラットフォームにドメイン駆動型 CQRS アーキテクチャを使用し、イベント ストア システムを使用して、新しいリリースでドメインが変更された場合にドメインにイベントをリロードできるようにしています。これまでのところ特別なことは何もありません。

私たちの作業協定の 1 つは、イベントを変更することは絶対に避けようとすることです。これは、実稼働環境のイベント ストア内のイベントの古いバージョンを壊すためです。イベントを本当に変更したい場合は、古いバージョン用のコンバーターを作成する必要があります。これは面倒で混乱を招く可能性があり、場合によっては不可能な場合もあるため、可能な限りこれを回避しようとします。

ただし、私たちはアジャイル ソフトウェア開発も行っています。つまり、私にとって (とりわけ) 「コードを前もって計画しすぎず、近い将来実際に使用されるコードだけを書く」ということです。これは、ほとんどの場合、私には理にかなっています。

しかし、これは前述のイベントで問題になります。新しいイベントを作成するときは、イベントを処理するすべてのシステムが必要なすべてのデータを保持できるように、関連するデータのほとんどすべてをそれに追加する必要があります。ただし、アジャイルの観点からは、その時点で実際に必要なイベントにのみデータを追加したいと考えています。

私の質問は次のとおりです。このジレンマを処理する最善の方法は何ですか? 私が考えることができる唯一の「解決策」は、編集なしのイベントルールを手放して、イベントコンバーターを作成する必要があることを受け入れるか、各イベントにできるだけ多くの関連データを追加しようとすることです。今後もデータが不十分な場合は、新しいイベントを作成します。

別の可能性は、単純に私たちの考え方に欠陥があるということです。このアプローチの最も弱い部分は何だと思いますか? これを処理するより良い方法はありますか?

この質問が理にかなっていることを願っており、他の視点を楽しみにしています:)

4

3 に答える 3

0

イベントをどのくらいの期間保存しますか?システムアップグレード中の「混合モード」操作の短期間の問題ですか、それとも複数の履歴バージョンのイベントをサポートする必要があるある種の長期ストレージモデルがありますか?

于 2013-02-13T16:08:19.567 に答える
0

「変更」は、妨げられるのではなく、受け入れられる必要があります。システムには、通常のソフトウェア ライフサイクルの一部として変更を受け入れるソリューションが組み込まれている必要があります。これに反対することは、それを「機能」として受け入れるソリューションを導入するよりも「費用がかかる」可能性があります。

私が彼を正しく理解していれば、私はアディと同じ方向に行くだろう. Event モデルをバージョン管理する必要があります。新しいソフトウェア バージョンを古いイベント モデルと互換性のあるバックウェアにすることを可能にする、親切なバージョン管理イベント/ソフトウェア システムを配置する必要があります。これは克服できない問題ではないと思いますが、建築図面に戻る必要があるかもしれません。

于 2013-12-18T21:45:31.730 に答える