Thinking about a Services Framework
Note: This series is not intended to break any new ground in particular. Instead it is a set of posts reflecting on a current project I have started and a way to document the thought process through the process.
What is service? At root a service is simply a unit of work that takes some form on input. Acts on the input and returns some sort of output. There may be side effects of the service call in the form of state change, upstream dependencies called, etc.
At heart the caller needs to identify the service to be called and then provide any input as needed to facilitate the service operation. Once the service has completed the operation then it will do one or more of the following:
- Perform a transient operation
- Retrieve data from a data store
- Store data in a data store
- Call a dependent service
The output will be governed by the service operation and could simply indicate whether the service succeeded or failed or additionally it may return a data object.
The service can be made available through any service context. This could be a web API, micro service, function as a service, job, console, queue handler, etc. Obviously difference services would lend themselves to different contexts for different use cases.
Next Steps
In part II we'll explore the different categories of output that we should anticipate from our service.
