While I agree with the overall idea here, something really odd struck me and that was that the author seems to assume that this would inevitably be some sort of microservice.
For so many companies, small to large, a microservice here would not just be an aditional point of failure as the article points out, but would totally over complexify the problem, when for most companies simply storing this data in their regular database, data store, whatever, and calling a relevant method to determine eligibility would suffice, and would require a hell of a lot less code.
customer.can_use_widgets? instead of customer.is_on_gold_plan?
customer.storage_allowance instead of customer.on_plan?("honkin' storage")
etc.
If you find that this won't scale at a later date then by all means turn it into a microservice, or add cacheing or whatever, but for most people that will never happen and time spent now solving the assumed scaling problems will be wasted.
Talking about an entitlement "service", not a term I see used for "another part of the same code base", talking about it being a new single point of failure, the seeming mapping out of a JSON API.
Service classes are a common pattern used in monolithic codebases to isolate related logic from the rest of the system. Everything the author described in the article can absolutely be built in a monolithic codebase sharing the same database, or separate databases if you prefer.
> Service classes are a common pattern used in monolithic codebases to isolate related logic from the rest of the system.
Yes, we have them in our code base. I'm pretty much 100% sure the author wasn't referring to these though, the way the author refers to "the service" is not how I've seen people refer to service classes.
> Everything the author described in the article can absolutely be built in a monolithic codebase sharing the same database, or separate databases if you prefer.
Yes, that, and the fact that the author seemed to assume that a microservice would be involved was what made me comment.
For so many companies, small to large, a microservice here would not just be an aditional point of failure as the article points out, but would totally over complexify the problem, when for most companies simply storing this data in their regular database, data store, whatever, and calling a relevant method to determine eligibility would suffice, and would require a hell of a lot less code.
customer.can_use_widgets? instead of customer.is_on_gold_plan?
customer.storage_allowance instead of customer.on_plan?("honkin' storage")
etc.
If you find that this won't scale at a later date then by all means turn it into a microservice, or add cacheing or whatever, but for most people that will never happen and time spent now solving the assumed scaling problems will be wasted.