Conception - comment gérer les événements sur les objets persistants lorsqu'ils changent d'état?

Question

Peut-être une question idiote, mais je suis un développeur novice.

Disons que, dans une application CRM'ish axée sur les données, j'ai un type de client qui peut passer par plusieurs phases - phases à savoir 1 - 5.

En tant que client change de phase - les événements doivent déclencher . Exemple - En tant que client entre la phase 3 de la phase 2, un e-mail est envoyé, certaines listes sont mises à jour et certains calculs sont effectués.

J'imagine qu'un état de changement de client pourrait être le résultat d'un utilisateur de l'application mettant à jour manuellement le client via une interface graphique. Donc je me demande - dois-je gérer cela en affirmant qu'il n'y a qu'une seule façon de mettre à jour l'état de phase du client, et ensuite s'assurer que chaque fois que cette action se termine, une liste d'actions sont effectuées? Dans mon esprit (et scénario), cela signifierait récupérer un client à partir d'une base de données relationnelle, mettre à jour un champ de phase, persister le client, puis toujours réagir à cette action en déclenchant toutes les actions enregistrées comme dépendantes ce changement de phase particulier. Cependant, je ne suis pas sûr que ce serait intelligent si je voulais faire un changement de phase de lot de 10.000 clients.

Des pensées à tout cela? Je cherche vraiment n'importe quel type de contribution - supposons que je suis complètement désemparé.

Answer 1

Je pense que c'est OK d'avoir des fonctions séparées, une pour un changement de phase client unique et un autre pour un changement de lot: ce dernier effectuera ou non les actions supplémentaires, selon les besoins, il pourra également le faire de manière plus efficace, ou même mettre en file d'attente les actions, ou une partie d'entre elles, comme l'envoi d'e-mails, Pour le traitement en arrière-plan, si les actions supplémentaires sont longues et que le changement de phase doit être achevé en temps voulu

Un autre problème apparaît lorsque le changement de phase est dû à l'apparition de certaines conditions, éventuellement complexes, qu'en raison d'un changement de phase manuel. ok une vérification de la condition quelque part dans votre logique métier, suffisamment faible pour intercepter toutes les opérations de mise à jour affectant la phase. Mais comme vous l'avez écrit, ce n'est pas le cas puisque dans votre situation, le changement de phase est émis manuellement.

Answer 2

Dans de nombreux cas, il est préférable d'avoir une fonction explicite dans votre logique métier pour modifier la phase. Cela devrait être le seul moyen de changer la phase, et c'est explicite. Comme "ChangeCustomerPhase" (Client client, Phase newPhase), il est beaucoup plus simple de gérer les changements si tout peut être changé librement