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

Question

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

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

Au fur et à mesure que le client change de phase, les événements doivent se déclencher. Exemple: lorsqu'un client entre dans la phase 3 à partir de la phase 2, un courrier électronique est envoyé, certaines listes sont mises à jour et certains calculs sont effectués.

J'imagine qu'un client qui change d'état peut être le résultat d'un utilisateur de l'application mettant à jour manuellement le client via une interface graphique.

Je me demande donc: devrais-je gérer cela en affirmant qu'il n'y a qu'un seul moyen de mettre à jour l'état de phase du client, puis en s'assurant que chaque fois que cette action est terminée, une liste d'actions est exécutée?

Dans mon esprit (et dans mon scénario), cela impliquerait de récupérer un client d'une base de données relationnelle, de mettre à jour un champ de phase, de persister pour le client, puis de toujours réagir à cette action en lançant toutes les actions enregistrées comme dépendantes de cette action. changement de phase particulier. Cependant, je ne suis pas sûr que ce serait intelligent si je voulais effectuer un changement de phase par lots de 10 000 clients.

Avez-vous des idées à ce sujet? Je suis vraiment à la recherche de tout type d’information. Supposons que je suis complètement désemparé.

Answer 1

Je pense qu’il est correct 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 effectuerait ou non les actions supplémentaires, selon les besoins. Il peut également le faire de manière plus efficace, ou même mettre en file d'attente les actions, ou une partie d'entre elles, telles que l'envoi d'e-mails, pour le traitement en arrière-plan, si les actions supplémentaires sont longues et qu'il est nécessaire d'effectuer le changement de phase en temps voulu. manière.

Un autre problème apparaît lorsque le changement de phase est dû à la survenue de certaines conditions, éventuellement complexes, plutôt qu’à un changement de phase manuel. Ensuite, vous devez associer une vérification de condition quelque part dans votre logique métier, suffisamment basse 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 cas, 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 changer de phase. Cela devrait être le seul moyen de changer de phase, et c'est explicite. J'aime & ChangeCustomerPhase (client customer, Phase newPhase). Cela simplifie considérablement le suivi du suivi des modifications si tout peut être modifié librement.