Unfortunately, I see the argument raging, and I don’t really have any sympathy with it. It seems to be an argument at cross purposes. One side argues that Entity Services are bad, another argues that DDD should be applied better. Are you even arguing?

At this point, I’d like to throw in that Microservices != DDD Bounded Contexts, and no matter how many people say it is so, they’re wrong.

"Microservices != DDD Bounded Contexts"

At its heart DDD is not an architectural approach. It is a software design discipline, probably the most comprehensive we currently have. Even so, it is not a way of creating architectures. I can approach a new software project and say "we will build this using a data flow approach, persist all events to provide deep analytics and provide HTTP facades for external integration". All of that is architectural thought, none of it design, and here DDD has not been used one iota.

Microservices, well, that’s plainly not a design approach, the radically different designs I see in the wild prove that. Instead, it’s a set of architectural principles. At its crudest, when you say "we want microservices", you are probably saying something along the lines of "we want to maintain the ability to change our software for longer, so will we introduce network boundaries to encourage isolation". No design, no entities, no data model, no API specs. Simple architecture, simple software philosophy.

This is where I see the issue arising, the fact that Microservices is apparently underspecified in terms of design, and so you must apply some form of design approach to do it properly. Most developers are used to an Object Oriented approach, and so reach for an Objects-in-the-large style design, the commonly seen "entity oriented microservices" (as I have tended to call them). This is not a new approach, its simply networked now. Look in the majority of spring applications (for example) and you will see precisely the same thing, a bowdlerised version of Model driven development approaches, the immediate precursor to DDD.