[okbake]

> According to SCS, the UI would be responsible for fetching that data from the other systems, and would pass all of it as part of the payload to the order fulfillment service.

One potential issue is that the order fulfillment service still needs to validate that the data its getting from the client is correct. For example, even if you send a list of full product details rather than a list of productIds to create the order, the fulfillment service still need a way to associate the Order entity with the Product entities. You could also send the ID with each of the products, but how would you know if the product has since been deleted or otherwise doesn't exist.

You end up needing the order service to either have its own set of knowledge about what products exist in the system for that user, or you need to make the synchronous call to ensure they're real products.

[lliamander]

Good point. The solution is obviously going to be context-specific. I suspect in our hypothetical order scenario that the order fulfillment system could get away with not validating the product being ordered.

Of course it would still need a way of capturing the identity of that product. I would guess that the best way to handle that would be to pass a URN or URI for the product. That would still decouple it somewhat from the product catalog system.

In general for these kinds of integrations, you're probably better off avoiding passing around system specific IDs. Pass data instead of IDs (pass the geocordinates or standardized address for a customers delivery address rather than the customer ID). If you have to pass around IDs, then URIs allow for greater decoupling.