Commands on Aggregate that not always need to create a new aggregate

464 views
Skip to first unread message

Koen Verwimp

unread,
Feb 28, 2017, 4:16:27 AM2/28/17
to Axon Framework Users
Hi,

I have a command that not always need to create a new Aggregate.
If it already exists, it should just load the existing. 
If it doesn't exists, it should create a new one first.

How to handle these types of commands? I guess this is not possible with an @CommandHandler annotation on the aggregate's constructor?

Do I have to create an "external commandhandler"?
If yes, how does this look like? Is this handler thread safe?

Kind regards,
Koen

jorgheymans

unread,
Feb 28, 2017, 11:03:01 AM2/28/17
to Axon Framework Users
We are doing this in a service before dispatching the command to Axon.

Koen Verwimp

unread,
Feb 28, 2017, 3:59:13 PM2/28/17
to Axon Framework Users
Thanks for you reply.

Is this not the responsibility for the command handler layer?
How do you check if the aggregate exists? You use the Aggregate Repo or a Read model?




jorgheymans

unread,
Mar 1, 2017, 1:30:46 AM3/1/17
to Axon Framework Users
We use the read model, we don't dispatch events async so this works great.

Allard Buijze

unread,
Mar 3, 2017, 4:46:41 AM3/3/17
to Axon Framework Users
What is a command handler layer?
All I know is "Command Handler", which is a component that handles a command. That component can be a singleton bean, or an Aggregate (in which case Axon will define a singleton bean that automatically loads the aggregate and forwards the command). There is nothing against that component doing a query to find out if an aggregate exists.

On the other hand, if you use client generated identifiers, the client should be aware already of an aggregate existing. The simple question is: "did you make up the UUID, or did you get it from somewhere?" In case it's the former, create the aggregate first, in case of the latter, just load and update.

Depending on how rare it is that an aggregate doesn't yet exist, you can also dispatch an update request, and if it fails, dispatch a create followed by the update (again).

Cheers,

Allard

On Wed, Mar 1, 2017 at 7:30 AM jorgheymans <jorg.h...@gmail.com> wrote:
We use the read model, we don't dispatch events async so this works great.

--
You received this message because you are subscribed to the Google Groups "Axon Framework Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to axonframewor...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply all
Reply to author
Forward
0 new messages