5

Eric Evans は DDD でモデルを進化させることについて多くのことを話しているので、DDD にはリファクタリングが不可欠のようです。世界のリレーショナル永続状態がある場合、データベース スキーマを変更する移行によってモデルの変更を処理できます。

イベント ソーシングを使用する場合、モデルの変更にどのように対処できますか? イベントの再生を妨げる互換性のない変更が集計にある場合、何らかのベスト プラクティスはありますか? それとも、やらないことですか？

4

3 に答える 3

4

イベントの再生を妨げる互換性のない変更が集約にある場合

このシナリオでは、基本的に 2 つのオプションがあります。

  • 古いイベントにパッチを適用して、互換性を持たせ、イベントを最初から再生できるようにします。ここでの利点は、履歴を失わないことですが、欠点は、古いイベントにパッチを当てるためにいくらかの労力を費やさなければならないことです。
  • スキーマ変更の時点で集計のスナップショット/メモを取得し、この時点からイベント ストリームを「再ベース」します。ここでの利点は、労力を費やす必要がないことです (イベント ソーシングを使用すると、スナップショット メカニズムが整っている可能性が高くなります)。欠点は、スナップショットの前からイベントを再生できなくなることです。

一般的な経験則として、スキーマを変更する前に履歴に戻って編集する必要があることが確実にわかっていない限り、デフォルトで 2 番目のオプションを使用することをお勧めします。

于 2013-08-03T08:30:42.403 に答える
3

私自身はあまり経験がありません。しかし、私はアップキャスティングと呼ばれる概念を見ました

もともとはオブジェクト指向プログラミングの概念で、「必要に応じてサブクラスがそのスーパークラスに自動的にキャストされる」というものでしたが、アップキャストの概念はイベント ソーシングにも適用できます。イベントをアップキャストするとは、イベントを元の構造から新しい構造に変換することを意味します。OOP のアップキャストとは異なり、イベントのアップキャストは完全な自動化では実行できません。これは、新しいイベントの構造が古いイベントに認識されていないためです。古い構造を新しい構造にアップキャストする方法を指定するには、手動で作成されたアップキャスターを提供する必要があります。

詳細については、 Axon のドキュメントを参照してください。

于 2013-08-03T02:51:43.213 に答える
2

イベントは単なる DTO です。イベント自体が変わらなければ、オブジェクトが 1 つある限り、モデルがどのように変化しても問題ありません。イベントを変更する必要がある場合は、必要なプロパティで「アップグレード」できます。Apply メソッドは、それをどう処理するかを認識します。詳細が分からないと何とも言えません。

モデルが大幅に変更され、基本的に以前の集約ルート (AR) ではなく 2 つの集約ルート (AR) を持つようになった場合、これは、古いイベントを使用しない新しい異なる集約があることを意味します。基本的に、古い AR から開始し、新しい AR を作成して、それらの AR に固有の対応するイベントを生成します。したがって、この場合、実際には互換性の問題はありません。

イベントの操作は、「従来の」OOP や RDBMS スキーマほど単純ではありませんが、ビジネス用語で考え、オブジェクトをドメインの概念として扱うと、より柔軟になります。モデルを変更するということは、ビジネス コンセプトの定義または使用法も変更されたことを意味するため、別の (永続性に関する限り新しい) コンセプトを扱っていることになります。

于 2013-08-03T09:23:55.200 に答える