Microservices that do not have a sufficiently mature business layer to solve their own tasks are examples of software built on an anemic domain.
The identification of an anemic domain can be done by making a few simple observations:
- The microservice cannot perform the tasks itself with only the data received
- The microservice needs to fetch data in more than one endpoint to perform a task
- The microservice does not have a self-sufficient entity model
- The microservice waits for the completion of a task in another microservice to follow up what you need to do
- The microservice needs to share resources with other external microservices; these resources can be cached to the sample database
If the microservice being developed is one of those items, then it can be a weak area. If a microservice has two or more characteristics of those listed, then it is definitely an anemic domain.
Anemic domains are very harmful to the microservices ecosystem, because they have a tendency to be multiplied in order to correct the technical debt generated by the deficiency in the composition of their respective domains.
