デザイン-永続オブジェクトの状態が変化したときに、それらのイベントをどのように処理しますか？

Question

これはばかげた質問かもしれませんが、私は新人の開発者です。

たとえば、データ駆動型のCRMのようなアプリケーションでは、フェーズ1から5までの多くのフェーズを経ることができる顧客タイプがあります

顧客がフェーズを変更すると、イベントがトリガーされます。 例-顧客がフェーズ2からフェーズ3に入ると、電子メールが送信され、いくつかのリストが更新され、いくつかの計算が実行されます。

顧客の状態が変化するのは、アプリケーションのユーザーが何らかのグラフィックインターフェイスを介して顧客を手動で更新した結果である可能性があることを想像しています。

だから私は疑問に思っています-顧客のフェーズ状態を更新する唯一の方法があると断言してこれを処理し、そのアクションが完了するたびにアクションのリストが実行されることを保証する必要がありますか？

私の考えでは（そしてシナリオ）、これはリレーショナルデータベースから顧客を取得し、フェーズフィールドを更新し、顧客を元に戻してから、それに依存して登録されているアクションを起動することで常にこのアクションに反応することを意味します特定の相変化。 ただし、10.000人の顧客のバッチフェーズ変更を行いたい場合、これがスマートになるかどうかはわかりません。

これに対する考えはありますか？私は本当にあらゆる種類の入力を探しています-私は完全に無知だと仮定します。

Answer 1

単一の顧客フェーズ変更用とバッチ変更用に別々の機能を使用してもかまいません。後者は、必要に応じて追加のアクションを実行するか、実行しません。追加のアクションが長く、フェーズの変更をタイムリーに完了する必要がある場合は、バックグラウンド処理のために、より効率的な方法でアクションを実行したり、アクションまたはメールの一部をキューに入れることもできます。マナー。

フェーズの変更が手動のフェーズ変更ではなく、いくつかの、場合によっては複雑な条件の発生に起因する場合、別の問題が発生します。次に、ビジネスロジックのどこかに、フェーズに影響するすべての更新操作をキャッチするのに十分なほど低い状態チェックをフックする必要があります。しかし、あなたが書いたように、あなたの状況では手動でフェーズ変更が発行されるため、そうではありません。

Answer 2

多くの場合、フェーズを変更するには、ビジネスロジックに明示的な関数を含める方が適切です。これは、フェーズを変更する唯一の方法である必要があり、明示的です。 ＆quot; ChangeCustomerPhase（顧客顧客、フェーズnewPhase）など。これにより、すべてを自由に変更できる場合に、変更を追跡する処理がはるかに簡単になります。