Entity services are a microservices anti-pattern, writes Tareq Abedrabbo, independent software consultant. The core reason for this is that they form shallow modules, where the interface is complex in relation to the functionality it provides.
Entity services are modelled after defined entities (or nouns) within a system. For example, an accounts service, order service and customer service. Typically they have CRUD like interfaces which operate on top of these entities.
By taking this CRUD like approach, entity services tend to not contain any meaningful business functionality. Instead, they are shallow modules, not really offering any complex or useful abstractions. Thus, in order to achieve functional requirements, coupling between these services ends up being introduced:
Entity services are conceptually small but shallow. They do very little aside from manipulating or exposing their internal state. As such, they often have to be composed in order to be useful, so in that sense, they are not truly decoupled or independent.
When complex queries require access to multiple data sources, they fall outside the remit of entity services and are often implemented as separate services or views atop their own data.
A good abstraction allows unnecessary details to be minimised and hidden, thus simplifying the way we think about the system. Entity services do not give good value for money compared to the complexity they add.
Ultimately, these shallow entity services can turn into a cluster of highly coupled components, write Abedrabbo. This leads to an operational burden, where more components must be deployed, scaled and monitored. This high coupling can also lead to challenging release processes, where many microservices must be deployed in order to deliver a single piece of functionality.
It can also produce single points of failure, where many services depend on each other, meaning that if one fails it can bring down the entire system.
Abedrabbo also explains that entity services create conceptual complexity, as the knowledge of how to compose them is not immediately obvious. This is because service composition can occur anywhere in the system and is often not straightforward.
The pattern can also lead to easy to make breaking changes:
More subtly, entity services, and shallow services, in general, provide no meaningful mediation or indirection between the interfaces they expose and the functionality they implement. Thus, the client of the system become unwittingly coupled to the implementation details of its services, all the way down to the database. In such situations, it becomes very difficult for the service implementer to modify or optimise the system without breaking everything because of this lack of a buffer between interface and implementation.
Abedrabbo concludes that there is no single approach for decomposing a system into microservices optimally. However, he advises on some best practices. These include driving design from business requirements, hiding information effectively, and avoiding shared contexts between microservices. The decomposition should also avoid the creation of single points of failure, allow parts of the system to be scaled independently, and make it easy to implement new functionality by keeping it within a single microservice boundary.