I've seen many folks who have come to the conclusion that CRUD services (aka 'Entity services') are an antipattern. Most recently, Udi Dahan asked me if I felt this way.
I have an interesting job at the moment. While the Enterprise Architecture team in Microsoft has been primarily focused on Governance, a project in the team that I was 'assigned to oversee' really needed an architect, so the Vice President of IT personally drafted me into that project. (I consider that an honor.) Unfortunately, it means I have two jobs (at least for now, but movement is coming).
- One job: look at the Enterprise... what is right, and what is composable and where does business agility lie.
- The other job: look at the problem space in an enterprise system: what is decoupled and what is interchangable and what is less costly to own.
And that is why I am slow to dismiss Entity services.
Because, as long as we are not sharing an entity service outside of a fairly tightly constrained 'area', I have no problem with creating an entity service and composing two or three activity services out of it. I wouldn't share the entity service beyond that tight space. I may still want to intermediate, but primarily for operational things like end-to-end transaction tracing and uptime monitoring... not to add logic.
The benefits of an entity services are all about decoupling. I can create an entity service on a single business entity off the data in one application, and then, as the business moves to another application, I can create another entity service with the same interface. I will STILL have to change my activity services (I'm not a fool), but hopefully I can minimize the change and therefore reduce the cost of change.
I cannot come up with an example of using an Entity service based on 'integration' because I cringe at the notion. If my order management system wants to create a customer in my relationship management system, I will NOT use a CRUD service. On the other hand, if my order management system needs to present a couple of different 'activities' to the world, I might stand up an entity service 'under the covers.' 'Assert an Order' (idempotent create) and 'Cancel an Order' (idempotent delete) are both Activity services. They may both use an 'Order Entity' service, for example, that is not visible to the enterprise but is still used to compose the activity services.
So, is an Entity service an antipattern? From the enterprise perspective, yes. From the application perspective, no. (these are not in conflict). I guess it depends on where you stand.