domain driven design - CQRS Event Sourcing check username is unique or not from EventStore while sending command -

eventsourcing works when have particular unique entityid when trying information eventstore other particular entityid having tough time.

i using cqrs eventsourcing. part of event-sourcing storing events in sql table columns(entityid (uniquekey),eventtype,eventobject(eg. useradded)).

so while storing eventobject serializing dotnet object , storing in sql, so, details related useradded event in xml format. concern want make sure username present in db should unique.

so, while making command of adduser have query eventstore(sql db) whether particular username present in eventstore. doing need serialize useradded/useredited events in event store , check if requested username present in eventstore.

but part of cqrs commands not allowed query may because of race condition.

so, tried before sending adduser command query eventstore , usernames serializing events(useradded) , fetch usernames , if requested username unique shoot command else throwing exception username exist.

as above approach ,we need query entire db , may have hundreds of thousands of events/day.so execution of query/deserialization take time lead performance issue.

i looking better approach/suggestion maintaining username unique either getting usernames eventstore or other approach

so, client (the thing issues commands) should have full faith command sends executed, , must ensuring that, before sends registerusercommand, no other user registered email address. in other words, client must perform validation, not domain or application services surround domain.

from http://cqrs.nu/faq

this commonly occurring question since we're explicitly not performing cross-aggregate operations on write side. do, however, have number of options:

create read-side of allocated user names. make client query read-side interactively user types in name.

create reactive saga flag down , inactivate accounts nevertheless created duplicate user name. (whether extreme coincidence or maliciously or because of faulty client.)

if eventual consistency not fast enough you, consider adding table on write side, small local read-side were, of allocated names. make aggregate transaction include inserting table.