January 31st, 2016
(written by lawrence krubner, however indented passages are often quotes). You can contact lawrence at: firstname.lastname@example.org
This seems like a great rule of thumb for microservices:
“We want to avoid dumb, anemic services that are little more than CRUD wrappers”
But it doesn’t cover the old territory which, if you were using Ruby or PHP, you would cover with a cron script. I suppose all the cron scripts must become functions that live inside the “service” which deals with a given part of the datastore. But that is not how my friends talk about “microservices”.
Page 58, Building Microservices, Sam Newman:
Whether you choose to become a REST ninja, or stick with an RPC based mechanism such as SOAP, the core concept of the service as state machine is powerful. We’ve spoken before about our services being fashioned around bounded contexts. [As an example,] our Customer microservice owns all the logic associated with behavior in this context.
When a consumer wants to change a customer, it sends an appropriate request to the customer service. The customer service, based on its logic, gets to decide if it accepts the request or not. Our customer service controls all lifecycle events associated with the customer itself. We want to avoid dumb, anemic services that are little more than CRUD wrappers. If the decision about what changes are allowed to be made to a customer leak out of the Customer service itself, we are losing cohesion.
Having the lifecycle of key domain concepts explicitly modeled like this is pretty powerful. Not only do we have one place to deal with collisions of state (e.g, someone trying to update a customer that has already been removed), but we also have a place to attach behavior based on those state changes.