> One of these services would probably be a Customer Service. In the > modeling effort we would identify the core properties of the > Customer object, and other objects that are related to the Customer > and belongs to the same Service. This core set of properties would > be the first version of the Specification of the Customer Service. > However, it would be the demand for customer information in > strategic processes that would be the trigger to actually go ahead > and build the Customer Service.
I think I understand now, seems like you have a more lightweight and more flexible alternative to what Erl is suggesting. I was however surprised in your other post when you said that you find updates to multiple (entity) services are rare though, I'd have thought it happens relatively regularly. For example if a pending credit check fails we will update the credit check itself and probably the related Customer, likewise if the Customer places (and pays for) a large Order we might update the Customer to indicate they should get special treatment. In both cases you've probably got two entities (or two entity services) being updated in one "transaction", how do you manage this? -Colin Jack
