DDD CQRS Concurrency issue

Question

We have set up an architecture based on DDD and CQRS. Additionally we have a restful API with an OAUTH implementation for our clients to connect to. Our clients connect to our API and perform operations on behalf of their clients. Their clients are represented by profiles on our side.

We don't have a good solution for the following problem. Clients are able to create a profile by calling a method on our API. The problem is that we need to guarantee the uniqueness of the profiles. So what we currently do is check for an existing profile in the read model, create a command if it doesn't exist and return the profile ID back to the client so they can perform other API calls.

When a client performs multiple calls in rapid succession, a profile is created twice instead of once due to an out of date read model. We don't want that, but how do we resolve this issue?

We have thought about creating a saga to prevent more than one profile being created in the domain, but that is still problematic because we need to return the same profile ID to the client if their request is the same.

Any thoughts?

Answer 1

Commands are not supposed to return results.

What you can do is create a command that includes the ID of the new profile, if it is a GUID. If you are using a seeded identity column of some sort, of course this won't work.

But say that your ID is a GUID. Then you can pass a GUID in the command to the back end. The back end will create the new profile only if the GUID doesn't already exist -- and you have guaranteed unicity.

Answer 2

From what I understand from the CQRS pattern, the command layer should not make use of the read model to take any decision. The command layer do its processing based on the domain it self. Not based ont he read model. Validation is always made ont the domain data. You profil creation command handler should check for the pre existence of the profil in the domain and not in the read model.

Answer 3

That's correct. Command should not rely on ReadModel, because of Eventually Consistent principle of ReadModel.

Just use your Domain in commands to make decision based on it.

Usually CQRS + EventSourcing repositories have very few methods, but on of them is GetById(Guid id). You can use it to check if such entity is already present in domain.