My take on this is that the “ApiGateway” services are acting as a “backend for front end” and converting between the front ends ViewModels and the back ends Models with some simple logic. You could add a service layer, but its unimportant to the overall architecture.
You could just as easily do this kind of “check the item Ids are valid” logic in the front end and connect direct to the back-end services, but you cant do it in the back-end services without coupling them.
The basket service accepts the itemId as an external Id from another system and it doesn’t care if that other system has the item or not. Adding that kind of coupling is something that they have chosen not to do when they choose the aggregate roots for the system as a whole and you wouldnt want to add it back in for fear of ending up with one massive service, rather than multiple microservices.
This choice is a key factor in DDD and questions such as:
- “what do i do when i need to actually deliver the items in a basket when the catalog doesn’t know what they are?”
- “how can i ensure the basket the customer is putting together only includes items from the catalogue?”
Are left to higher layer “Delivery” and “WebShop” Domain Services or Objects. You have to be careful to keep your services hierarchical, loosely coupled and avoid circular references.
A common pitfall for example would be to add a ICatalogue reference to the Basket service and then later add a IBasket reference to the Catalogue service. Everything would compile, but in reality you wire up one service to the other and have potential infinite loops, or at least inefficient calling back and forth and your choice of ARs is called into question.