Read model for aggregate in DDD CQRS ES

Question

In CQRS + ES and DDD, is it a good thing to have small read model in aggregate to get data from other aggregate or bounded context?

For example, in order validation (In Order aggregate), there is a business rules which validate order only if customer is not flagged. The flag information is put in read model (specific to the aggregate) via synchronous domain events.

What do you think about this ?

Answer 1

is it a good thing to have small read model in aggregate to get data from other aggregate or bounded context?

It's not ideal. Aggregates, due to their nature, are not good at enforcing consistency that involves state outside of themselves.

What this usually means is that the business is going to need some way to respond when two aggregates produce an unacceptable state.

You also have the option of checking for the flag before you run the placeOrder command on the aggregate. That check for the flag could be done in the command handler, or in the client -- basically, you have was of "validating" that the command should succeed before passing it to the aggregate.

That said, if it were critical to try to consult the read model while processing the command, a way to do it would be to use a "domain service"; you pass a service provider to the aggregate as part of the command, and let the interface abstract away the fact that running the query requires looking outside of the aggregate.

That gives you some of the decoupling you need to keep the aggregate testable.

Answer 2

It's doable, but not in the form of a read model, rather a Value Object in the Aggregate (since we're on the Write side).

If you already have a CustomerId in Order , you just have to compose a VO with it and a Flagged member.

Of course, this remains prone to all the problems of cross-aggregate communication since the data originates from Customer . Order has to be kept in sync with the flagged status of its Customer, which can require quite a bit of work.

In any case, you should probably first determine with your domain expert whether immediate consistency is an absolute requirement (in which case you have to somehow wrap Customer + Order in a transaction) or if you can afford a small delay in Flagged freshness when enforcing that invariant. If the latter, you can choose between duplicating Flagged in the Order aggregate or the first option given by @VoiceOfUnreason - the main difference being probably that if the data is in the aggregate, you'll get it for free at the Domain level should you need it in multiple occasions, instead of duplicating the check in multiple use cases/command handlers at the application level.