Design - how do i handle events on persisted objects as they change state?

Question

Maybe a silly question this, but I'm a rookie developer.

Lets say, in a data-driven CRM'ish application, I have a customer type that can go through a number of phases - i.e. phases 1 - 5.

As a customer changes phase - events should trigger. Example - as a customer enters phase 3 from phase 2, an email is sent, some lists are updated and some calculations are performed.

I'm imagining that a customer changing state could be the result of a user of the application manually updating the customer through some graphic interface.

So I'm wondering - should I handle this by asserting that there's only one way to update the phase state of the customer, and then insure that whenever that action completes, a list of actions are carried out?

In my mind (and scenario) this would mean retrieving a customer from a relational database, updating a phase field, persisting the customer back down, and then always reacting to this action by firing off whatever actions are registered as dependent on that particular phase change. However I'm not sure this would be smart if I wanted to do a batch phase change of 10.000 customers.

Any thoughts at all to this? I'm really just looking for any kind of input - assume that I'm completely clueless.

Answer 1

In many cases it's better to have a explicit function in you business logic to change the phase. This should be the only way to change the phase, and it's explicit. Like "ChangeCustomerPhase(Customer customer, Phase newPhase). This makes it much simpler to handle that to track changes if everything can be changed freely.

Answer 2

I think that's OK to have separate functions, one for a single customer phase change and another for a batch change. The latter would or wouldn't carry out the additional actions, as needed. It could also do it in a more efficient way, or even enqueue the actions, or part of them, like sending e-mails, for background processing, if the additional actions are lengthy and it is required to complete the phase change in a timely manner.

Another issue pops up when the phase change is due to the arising of some, possibly complex, conditions, rather than due to a manual phase change. Then you should hook a condition check somewhere in your business logic, low enough to catch all update operations affecting the phase. But as you wrote, that's not the case since in your situation the phase change is issued manually.