Question

I am currently using J Oliver’s EventStore and I want to know how I can check if an aggregate exists when I do my call (GetById(Guid id))?

Following how CQRS works, should I be querying the read database or should I somehow find out if there is a corresponding aggregate in the EventStore?

Answer 1

The way the EventStore works at the moment, you will create a new Stream (Aggregate root) if the stream is not found.

Check this line:
https://github.com/joliver/CommonDomain/blob/master/src/proj/CommonDomain.Persistence.EventStore/EventStoreRepository.cs#L53

It calls this method on the Store:
https://github.com/joliver/EventStore/blob/master/src/proj/EventStore.Core/OptimisticEventStore.cs#L45

Which calls this constructor:
https://github.com/joliver/EventStore/blob/master/src/proj/EventStore.Core/OptimisticEventStream.cs#L27

The effect is that it will either populate the Stream using Commits that it found in the persistence, or if none are found it will do nothing and return the new Stream.

However, you shouldn’t have to ask yourself this question. A Command should be validated before you send it. Use your read models to validate the command before you send it.

Also, the Command together with Aggregate root state should be enough information to perform your decision in the domain. This basically means that you have to be certain of the domain state before you send your commands in order to avoid exceptions in the domain. And you can use the the read model for that.

Update as a response to Mauros comment:

You are having a concurrency issue. You might be able to solve it by using the method used in occasionally connected systems which is merging. What you can do is to store the Stream revision in the read model so that you know which revision of the AR you have acted upon. Then when the command is handled you know if you were acting upon an old state of the AR.

If the AR revision is higher than than the one the command brings you can either discard the command as a failure (pessimistic concurrency), or you can try to merge the changes.

This can be done by looking at the events produced from the revision in the command up until the current state. Then invoke the behavior the command was supposed to do and look at the events created by that behavior and compare the two event collections. If there aren’t any conflicting events, you can commit the newly created events to the store. If there are conflicts, you can throw a concurrency exception.

I think that is your best bet to solve this type of concurrency issues.

Search for Event Merging for more info.