DDD/Event sourcing, getting data from another microservice?

Question

I wonder if you can help. I am writing an order system and currently have implemented an order microservice which takes care of placing an order. I am using DDD with event sourcing and CQRS.

The order service itself takes in commands that produce events, the actual order service listens to its own event to create a read model (The idea here is to use CQRS, so commands for writes and queries for reads)

After implementing the above, I ran into a problem and its probably just that I am not fully understanding the correct way of doing this.

An order actually has dependents, meaning an order needs a customer and a product/s. So i will have 2 additional microservices for customer and products.

To keep things simple, i would like to concentrate on the customer (although I have exactly the same issue with products but my thinking is that if I fix the customer issue then the other one is automatically fixed also).

So back to the problem at hand. To create an order the order needs a customer (and products), I currently have the customerId on the client, so sending down a command to the order service, I can pass in the customerId.

I would like to save the name and address of the customer with the order. How do I get the name and address of the customerId from the Customer Service in the Order Service ?

I suppose to summarize, when data from one service needs data from another service, how am I able to get this data.

Would it be the case of the order service creating an event for receiving a customer record ? This is going to introduce a lot of complexity (more events) in the system

The microservices are NOT coupled so the order service can't just call into the read model of the customer.

Anybody able to help me on this ?

Answer 1

If you are using DDD, first of all, please read about bounded context. Forget microservices, they are just implementation strategy.

Now back to your problem. Publish these events from Customer aggregate(in your case Customer microservice): CustomerRegistered, CustomerInfoUpdated, CustomerAccountRemoved, CustomerAddressChanged etc. Then subscribe your Order service(again in your case application service inside Order microservice) to listen all above events. Okay, not all, just what order needs.

Now, you may have a question, what if majority or some of my customers don't make orders? My order service will be full of unnecessary data. Is this a good approach?

Well, answer might vary. I would say, space in hard disk is cheaper than memory or a database query is faster than a network call in performance perspective. If your database host(or your server) is limited then you should not go with microservices. Moreover, I would make some business ideas with these unused customer data e.g. list all customers who never ordered anything, I will send them some offers to grow my business. Just kidding. Don't feel bothered with unused data in microservices.

Answer 2

When data from one service needs data from another service, how am I able to get this data?

You copy it.

So somewhere in your design there needs to be a message that carries the data from where it is to where it needs to be.

That could mean that the order service is subscribing to events that are published by the customer service, and storing a copy of the information that it needs. Or it could be that the order service queries some API that has direct access to the data stored by the customer service.

Queries for the additional data that you need could be synchronous or asynchronous - maybe the work can be deferred until you have all of the data you need.

Another possibility is that you redesign your system so that the business capability you need is with the data, either moving the capability or moving the data. Why does ordering need customer data? Can the customer service do the work instead? Should ordering own the data?

There's a certain amount of complexity that is inherent in your decision to distribute the work across multiple services. The decision to distribute your system involves weighing various trade offs.

Answer 3

My suggestion would be to gather the required data on the front-end and pass it along. The relevant customer details that you want to denormalize into the order would be a value object. The same goes for the product data (e.g. id, description) related to the order line.

It isn't impossible to have the systems interact to retrieve data but that does couple them on a lower level that seems necessary.