Unique field validation

[imissyouso]

refers to #70, #91

Hi, I have the similar question: how to make checks for uniqueness in domain?
I tried to check it using eventDenormalizer by saving unique values (emails) into VM by listen domain events and then check it in preCondition:

import * as domain from "cqrs-domain";

export = domain.definePreCondition({
    // @ts-ignore
    name: ['createUser', 'updateUser'],
    priority: 1,
    payload: 'payload',
},  (data, aggregate, callback) => {
    const usersRepo = require('../viewBuilders/user/usersCollection');
    usersRepo.findViewModels({email: data.email}, (err, items) => {
        if(items.length){
            callback("Provided email is already exist in our database!");
        } else {
            callback(null);
        }
    });
});

but this way is not atomic, theoretically there can be situation when 2 users can create their accounts with the same emails. How to avoid this?

[imissyouso]

Also the way

If you really want to solve it in the domain, you need only 1 aggregate instance i.e. with a fix aggregate id (i.e. USER_EMAILS)

is not a suitable because for every check we need to load the whole aggregate with full list of emails and then make check directly in code (in cycle?). What if we have > 1k users? We cannot make such complex operation just for simple checking for uniqueness.

Thanks for reply in advance.

[adrai]

Hehe... welcome to the cqrs world...
Do not mix domain and eventDenormalizer stuff that way.
To solve this you really need 1 aggregate.
To make this more efficient when having too much events, there are snapshots.

[imissyouso]

Found similar question on stackoverflow
https://stackoverflow.com/questions/31386244/cqrs-event-sourcing-check-username-is-unique-or-not-from-eventstore-while-sendin
conclusion: there is no universal way how to do that. In most cases we have to put up with possible data inconsistency in such types of architectures and do not try to hack CAP theorem.

[nanov]

Having what @adrai said in mind, there are a few patterns you can apply to solve your problem, after you have decided that cqrs/es is suitable for youe user/account management:

• in your case you can set the aggregate id as the email, and give the command a rule that the aggregate does not exists.

• you may take a look on this answer that i gave for similar question - as last resort this is a solution.
  In your case

[dmitry-textmagic]

The second approach is quite clear. But in the first one, how should we manage email change? If we set an email as an aggregate id, then change email (and it was aggregate id), it causes that any other entities that have this aggregate id (email, in this case) inside would be linked to non-existent/invalid aggregate.

[adrai]

This is why I said, you need 1 aggregate for all email addresses...
Or solve this outside of cqrs.
PS. sorry for not responding with a more complete/longer answer... writing from hospital

[imissyouso]

This is why I said, you need 1 aggregate for all email addresses...
Or solve this outside of cqrs.
PS. sorry for not responding with a more complete/longer answer... writing from hospital

I wish you a speedy recovery!