Validate existence of another aggregate
158 views
Skip to first unread message
Federico G
Sep 19, 2017, 4:08:31 PM9/19/17
to DDD/CQRS
Hello,
When using CQRS, how should I validate the existence of another aggregate? For example, when creating an order I need to validate that the customer exists, and I have the customer ID (applying the rule of referring to other aggregates by id only) as part of the CreateOrder command data.
Assuming I have a CustomerRepository injected to perform the validation, I see two options to query the customer for existence inside the repository:
1. Validating against a customer Read Model - easiest choice, need to be careful if applying eventual consistency or I could hit false negatives.
2. Validating against a customer Aggregate rehydrated from events - no eventual consistency issue, but it seems as an overkill to do this only to check for existence (and I understand the Aggregate is used only for sending commands, not for querying).
How would you handle this? Is there another option?
When using CQRS, how should I validate the existence of another aggregate? For example, when creating an order I need to validate that the customer exists, and I have the customer ID (applying the rule of referring to other aggregates by id only) as part of the CreateOrder command data.
Assuming I have a CustomerRepository injected to perform the validation, I see two options to query the customer for existence inside the repository:
1. Validating against a customer Read Model - easiest choice, need to be careful if applying eventual consistency or I could hit false negatives.
2. Validating against a customer Aggregate rehydrated from events - no eventual consistency issue, but it seems as an overkill to do this only to check for existence (and I understand the Aggregate is used only for sending commands, not for querying).
How would you handle this? Is there another option?
Greg Young
Sep 19, 2017, 4:24:32 PM9/19/17
to ddd...@googlegroups.com
Why would you need to load all events to check for existence? Couldn't you just see if the stream exists?
--
You received this message because you are subscribed to the Google Groups "DDD/CQRS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+unsubscribe@googlegroups.com.
Visit this group at https://groups.google.com/group/dddcqrs.
For more options, visit https://groups.google.com/d/optout.
Studying for the Turing test
Federico G
Sep 19, 2017, 4:40:11 PM9/19/17
to DDD/CQRS
Genius, thanks!
What about more complex validations, for example: customer is not blacklisted. In that case, would you use event-based rehydration or read model query?
What about more complex validations, for example: customer is not blacklisted. In that case, would you use event-based rehydration or read model query?
On Tuesday, September 19, 2017 at 5:24:32 PM UTC-3, Greg Young wrote:
Why would you need to load all events to check for existence? Couldn't you just see if the stream exists?
On Tue, Sep 19, 2017 at 9:08 PM, Federico G <fed...@gmail.com> wrote:
Hello,
When using CQRS, how should I validate the existence of another aggregate? For example, when creating an order I need to validate that the customer exists, and I have the customer ID (applying the rule of referring to other aggregates by id only) as part of the CreateOrder command data.
Assuming I have a CustomerRepository injected to perform the validation, I see two options to query the customer for existence inside the repository:
1. Validating against a customer Read Model - easiest choice, need to be careful if applying eventual consistency or I could hit false negatives.
2. Validating against a customer Aggregate rehydrated from events - no eventual consistency issue, but it seems as an overkill to do this only to check for existence (and I understand the Aggregate is used only for sending commands, not for querying).
How would you handle this? Is there another option?
--
You received this message because you are subscribed to the Google Groups "DDD/CQRS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+u...@googlegroups.com.
Visit this group at https://groups.google.com/group/dddcqrs.
For more options, visit https://groups.google.com/d/optout.
Greg Young
Sep 19, 2017, 4:48:16 PM9/19/17
to ddd...@googlegroups.com
depends on consistency assurance, likely a read model is good enough
To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+unsubscribe@googlegroups.com.
Visit this group at https://groups.google.com/group/dddcqrs.
For more options, visit https://groups.google.com/d/optout.
Reply all
Reply to author
Forward
0 new messages