Given two services A and B, with B handling an event from A (through a broker), consider the that you want to do some operations in A and need data in B to query data in A.
You could do an HTTP request to a rest endpoint in B, use the data and do whatever you wanted to in A. Well I’ve read around that services should be self contained, that is if you need data in A that is found in B, have a copy of that data in A.
Another option will be to apply an event in A that is handled in B, and have B send the data back to A through another event. In my perception, this breaks the DDD principle that a command should only be used to modify state.
What option (including any other not mentioned) do people usually use?
First of, I’m taking the stance you’re talking about an Axon application.
Sounds like you need to perform a ‘complex business transaction’ between different services and want to send messages to each other.
This is typically were a saga comes into play which would do that orchestration for you.
So in your example the Saga would gather the required state from service A and B through events applied from either.
When the Saga is in a certain state you can then perform actions on service A and B by publishing a command.
Without a specific use case, I’m hard pressed to be a 100% certain this is the approach you have to take, but on first glance this is what I’d suggest in this abstract scenario.
For the complex business transaction, I have another use case where I need to do that. I’ve asked a question on that in another thread. However, this is not the case here. A needs to query data from its database, but part of its query filter depends on information on B. It’s kind of a JOIN in a monolith.
What I mean is that A has to carry out an operation that doesn’t need handling in B. But B contains data that A needs in its process
Ideally, the two services would be able to run autonomously, meaning that they each build up their own models containing the information they need to make decisions. However, this may generate a level of coupling in services that becomes inconvenient. For example because you need to start processing events to build up a model that (i) is already being built up somewhere else and (ii) may not be used at all, depending on the situation.
An alternative is for the components to query for the information. How the query is executed (HTTP, Rabbit, etc) is merely a technical detail. That’s a choice you make after deciding you need a query at all. A query doesn’t give you the same coupling as building up a model based on events does. However, you do get runtime coupling in return (i.e. the other components needs to be available).
Whether you take one approach or the other, depends on many factors. That’s essentially what the strategic design of DDD is about: defining context boundaries and their relationships. Try to come up with the pros and cons in your specific case for each scenario and then pick the least of two evils.