SERVICES: [Part 4 of 6]
In “The Method” the services make up the system. The services encapsulate our core use cases, grouped by areas of volatility. What the services don’t attempt to do is reflect the state the application. Not just this app, any application.
A core principles of services is that they get used by many applications. Services that had knowledge of an application’s state would be useless for reuse. (Apps may use services to store their state. The service itself should be agnostic to any knowledge of application state.)
By eliminating the complexities of application state we make building services easier.
This lack of state is what makes service calls transaction-able. We begin a service call, it performs it’s job, and we get a response. In this model service calls works or they don’t. The transaction succeeds or it doesn’t. Applications don’t have this luxury. They must deal with the user, the workflow, the “what’s next.” Very often the “what’s next” is determined by “what was.” It’s all state management. With our services we try hard to avoid this.
You’re services perform core business functions. They get in and get out, then their done.
You’re applications are complex, multi-state beasts. They live long lives and deal with complex situations. They have to have contingencies for the contingencies (remember that scene from the movie Inception where they have to go into the dreamer’s dream within the dream they’re already in?). Your apps are one big version of our own production of Inception. State matters. In our services we don’t want it to matter at all.
Why is this important and how does it help us with “The Method?”
[part 5]
