Hacker News Reader

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.

> which you lose across service-boundaries.

I suspect this gets resolved at this company by composing on the UI a ton. The UI can reach in and get Orders from the Orders microservice, then reach out to the LineItem microservice. Before this post, I've argued at it the other way: "A LineItem will always require an Order in context therefore maybe LineItem should be part of the Order service instead of it's own thing."

Since this isn't the first time I've seen this heavy UI composition in my career, I suppose it's time to coin and describe this DDD antipattern :)

Yeah that "engineers per service" equation seems alarming. I think we're essentially at a 1:1 ratio at a glance ; not evaluating whether there are "private microservices."

We did something like DDD:

- we did the ubiquitous language part, working with clients to arrive at consistent, particular language to describe the problem

- we then made a big chart of things and their relationships; get clients to sign off this describes problem

- but we didn’t bother with any formal steps passed that; we just took the chart as a systems diagram and implemented that

There’s some deep sense in which any program which encodes the chart is a type embodying the semantics of the chart, viewed as a categorical diagram. So it’s not too surprising this works out alright.

I think the ubiquitous language part of DDD is great; I’m not sure it has much to say about turning domain diagrams into software.

> Using the examples in this article, they might have made a "LineItem" microservice along with their "Order" microservice. This seems obviously awkward when thinking about doing this for something more commonly understood like "Order" but in our more niche domain model it isn't as obvious. So that's great to have some language/categories to point out that "LineItem" is not a an "Aggregate Root" and thus it is a indicator that it may not need to have it's own bounded-context/microservice. "Order" is an "Aggregate Root" and so it is a stronger candidate for it's own bounded-context/microservice.

EJB 1.0 specification made all entity beans remote. This lead to every interaction with every entity in the system cross a process boundary, the way you describe here. This was soon recognized to be an anti-pattern. Soon, a pattern called "Session Facade" was identified - the remote interfaces are coarse-grained operations, working on aggregate roots.

Microservice-per-entity is EJB 1.0 all over again.