Entity Services

Entity services are microservices carved out along data-entity lines — a Customer service, an Order service, an Address service — each essentially a CRUD wrapper over one table. The decomposition follows the data model rather than business capabilities, which sounds reasonable but tends to produce a brittle, chatty architecture.

Why It Happens

Entities are the most visible structure in a system, so splitting by them feels natural and objective. It mirrors the database schema, which is easy to reason about. Teams equate "one noun, one service" with good design. Without domain analysis, capability boundaries are invisible while entity boundaries are obvious, so entities win by default.

Why It Hurts

Real business operations span multiple entities, so completing one task requires orchestrating several entity services, producing chatty cross-service traffic and distributed transactions. The services themselves become anemic — just data access with no behavior — while the actual business logic leaks into orchestrators or clients, which then become coupled to many services. Because entities are highly interconnected, the services end up tightly coupled rather than autonomous, undermining the independence microservices are meant to provide. You get the cost of distribution without the benefit of decoupling.

Warning Signs

• Each service maps one-to-one to a database table.
• Services expose only CRUD and contain no business rules.
• Business logic lives in an orchestration layer that calls many services.
• Simple operations require coordinating several services.

Better Alternatives

Decompose by business capability, not by entity. Use domain-driven design to find bounded contexts — each owning the data and behavior for a cohesive part of the business — so a service can complete meaningful operations largely on its own. A capability-aligned service may own several entities that change together, keeping related logic and data inside one boundary and reducing cross-service chatter.

How to Refactor Out of It

Model the domain to identify capabilities and their natural boundaries. Group entity services that collaborate to fulfill a capability into a single capability-aligned service that owns those entities and the logic over them. Move orchestrated business rules into the owning service so behavior lives with data. Reduce cross-service calls by co-locating what changes together. The test of a good boundary: the service can perform its core operations without a flurry of calls to others. Capability services give cohesion and autonomy that entity services cannot.