Aggregate's client generated identifiers

Hi Allard,

I’m using client generated identifiers for Aggregates in a microservice environment. It is a common case one service to initiate aggregate create command to another service.
In my architecture I’m using REST API for sending commands between microservices. (I’m having my reasons to prefer this approach vs distributed command bus).

Eventually it can happen, that one microservice can repeat CreateXyzCommand to the Aggregate owner’s microservice. If this happens I need to be able to handle it and send an appropriate HTTP status code to the caller, so that it is aware that requested Aggregate was already created.

In order to do this I need some specific exception (for example: DuplicateIdentifierException) to be thrown, when I try to create aggregate with identifier, that already exists. Now I get some general purpose EventStoreException, that does not tell what is the reason for the failure. I don’t want to handle this behavior in my command handlers or services (unfortunately what I’m doing now)

What do you think?


Hi Plamen,

it’s actually already possible to identify this case. If you configure your EventStorageEngine with a PersistenceExceptionResolver (or a DataSource, in which case one is automatically configured based on the type of database backing your applicaiton). The PersistenceExceptionResolver checks if the exception thrown from the EntityManager is a DuplicateKeyException. In that case, the JpaEventStorageEngine throws a ConcurrencyException instead of the generic EventStorageException.