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.