This post is part of a series. Click here for the ‘home page’
The consequence of invoking a service is the realization of one or more real world effects. These effects may include:
- Returning information in response to a request for that information
- A change in the shared state of defined entities
- A combination of both
Note that the shared state does not necessarily refer to specific state variables being saved in physical storage but it is really a “mutual understanding” between the provider and consumer. For example, if I make an airline reservation, the airline and I have a mutual understanding that I will be travelling on a specified date. There is no “physical” data source that is shared between us.When thinking about real world effects in your architecture, consider such things as:
- Does the consumer need to know ANYTHING about the internal (private) workings of a service? Does the provider need to know anything about the consumer? Each party should not have any knowledge of the internal workings of the other.
- If the interaction between a provider and consumer is a sequence of events, how do you manage ‘incomplete’ state (i.e. when the sequence is not yet complete)?
- Is there sufficient auditing/logging of real world effects?
- Are ALL real world effects clearly understood by the consumer? Or is there any side effects of the interaction that the consumer may not be aware of?
- Are the real-world effects clearly understood by consumers? For example, if you call a “BookFlight” service and no seats are available, the service may notify the consumer of that fact OR it may automatically put the person on a waiting list – this is also a real world effect but unless the consumer knows that this will happen it is not the real world effect intended by the consumer.