I think what you describe is a mis-application of DDD. One service per entity is way overkill and nothing like Evans would advocate for. As you note, the whole

I think what you describe is a mis-application of DDD. One service per entity is way overkill and nothing like Evans would advocate for. As you note, the whole point of Aggregates is that you can select all the sub-entities in one DB transaction, which you lose across service-boundaries. One domain service per Bounded Context is the starting point I usually see. And you can decompose into “private microservices” implementing components within a BC as needed. You might also have many “infra services/components” implementing that logical service for the BC. (For example, a service might have Django API, RabbitMQ, Postgres, Redis, Celery components. And you could split an auth microservice from the API if needed for isolation. But the external Service API remains the set of operations that make sense within a BC.) It sounds like this company might be approaching “services per engineer” instead of measuring “engineers per service”, which is a red flag for me. There is alot of overuse of the microservice pattern as part of the hype wave.