3

When working on an application in microservices architecture I stumbled upon issues concerning coupling between services.

This a typical application for ordering products. It seams reasonable to have a service that will operate as a product catalog. Our JavaScript client can ask this service for available products and show them in browser. When user clicks on a product we have to create an order. We would like to manage orders in another service. So an order is created - it means that user X ordered product Y. On the technical level we are simply persisting user id and product id in a database.

To sum up we have:

Products service

Product class:
Product ID, Product Name

Orders service

Order class:
Order ID, Product ID, User ID, Order date

Now let's imagine following scenario - in JavaScript client we would like to list all products that user have ordered. Orders service provides a list of products ids for a given user. But user cares about product name, not the id. Unfortunately Orders service doesn't know anything about products names.

We could tackle this in couple of ways:

  • Simply assume that the client is responsible for getting the information it needs. So after it calls Orders service and gets a list of products ids, it performs another call to Products service, passing products ids and getting corresponding products names in response. Then the client assembles both responses into something useful. This approach keeps our services clean, without leaking of domain knowledge from one service to another. But it requires more work on the client side.

  • Orders service when asked for ordered products makes a call on the backend to the Products service. It retrieves product names, assembles a response that contains orderDate and productName and sends that to client. All that's left for client to do is to present the data. Downside of this approach is that Orders service now gains more knowledge about products than neccessary.

  • Duplicate information about product name in Orders service. When an order is created, we pass not only product id but also product name. That means that Order class will look like this: Order class:
    Order ID, Product ID, Product name, User ID, Order date
    Now we can easly provide full information about order without additional call to Products service. Also this time Orders service has too much knowledge about products. What's beneficial tough is that Orders service can provide relevant data even if Products service is down.

Could any of these approaches be considered best practice? Or are there different solutions?

dhclaw
  • 63
  • 6
  • Duplicate the info. It isn't true duplication. If you change product name in future what should the user see? As it was at order probably so it isn't really duplication. – GraemeMiller Jul 01 '18 at 11:43
  • I agree, duplicating just the data that is required seems the sensible option. If required you could also look at using message queues to push product name or price changes into the basket pre-order. After the order has taken place, the information probably shouldn't change about a product. – Adam Jul 01 '18 at 19:08
  • 1
    Agreed. Until order completes price could change. That is how Amazon works. Stuff in basket etc keeps changing price. Once order completes that has to be captured at point in time. Can't change agreed price without telling customer. – GraemeMiller Jul 01 '18 at 19:55

1 Answers1

4

In the eShopOnContainers example( https://github.com/dotnet-architecture/eShopOnContainers ), they add the following fields at the time an order item is created:

        public void AddOrderItem(int productId, string productName, decimal unitPrice, decimal discount, string pictureUrl, int units = 1)

This duplicates the catalog information, however as this is a point in time snapshot of the record. This is far safer than linking to the original data.

At this point in the user journey you are in the domain of an order, if a user is viewing an order you can provide a link to the catalogue. However, the order service should be able to operate independently. Linking back to the catalogue for the information on products prevents the Order service owning it's own data.

A nightmare scenario being that a price changes in the catalogue... What would happen to the historic orders?

Adam
  • 1,149
  • 10
  • 12