> Using the examples in this article, they might have made a "LineItem" microservice along with their "Order" microservice. This seems obviously awkward when th

> 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.