How to check for an Aggregate's uniqueness on a property ?

[chelios....@gmail.com]

Suppose I have an application where I need to register users but all users should have unique email addresses.

CreateUserCommand(email: String, password: String)

I've read that the client (Rest layer) should query the Read side to validate email uniqueness before sending the CreateUser command to the write side but what if the write side creates a User with email 'us...@email.com' and before this user gets updated on the read side database another user registers with the same email address ? 

I know I can block and get a confirmation from the read side that user with 'us...@email.com' is committed before processing another CreateUser command with the same email address. But what is the recommended approach ?

[Danil Suits]

Recommended reading:

http://codebetter.com/gregyoung/2010/08/12/eventual-consistency-and-set-validation/

The money quote: "What is the business impact of having a failure"

But what is the recommended approach ?

As best I can tell, there are reasonable approaches

1. If the impact is small (duplicate email addresses are rare, recovery is cheap), then let the client layer suffice.
2. If the data that you need to be unique is stable, then you can use that data as the seed for your identifier, and then you just need to prevent duplicates.  People often change email addresses, so that approach is probably out.
3. If your system of record has good set validation facilities (for instance, a relational database); then you can take the uniqueness constraint out of the domain model and let the system of record provide it instead.
4. If all else fails, you can create an aggregate in your domain model that is responsible for maintaining the uniqueness constraint.  This might cascade through your model (if the user entity you are creating isn't part of this aggregate, then you still have consistency challenges, but you have more control?)

I haven't yet seen any discussion of advanced approaches when the system of record is an event store.  The closest I've seen asks the question "are you sure you are modeling the right thing?"

https://groups.google.com/forum/#!searchin/event-store/set$20validation/event-store/o_Y2exIxNZM/vZzuVld23lwJ

Beyond that, I'm super suspicious of this question; what is your domain that you are doing email/password?   Reality check: who are your domain experts?  If you have been talking to a bunch of security experts, using that ubiquitous language, great.  Otherwise, I question whether you are packing the right stuff into your domain model.

(Riddle: what business rules in your domain depend upon User.email ? )

[Greg Young]

You can even put say an infrastructure service and insert into a db
with a unique constraint as part of the write operation. The trade off
however is that if you do this you also run the risk of a wide spread
outage (what happens if that db is down?)

> --
> 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.
> For more options, visit https://groups.google.com/d/optout.



--
Studying for the Turing test