Axonframework: Allow command handlers to be declared at different levels of aggregate class hierarchy

Created on 23 Mar 2017  路  7Comments  路  Source: AxonFramework/AxonFramework

Per the discussion in https://groups.google.com/d/topic/axonframework/FhWk-OMPgZc/discussion -- in Axon 2 it was possible to have an aggregate class hierarchy where common command handlers were declared on the superclass and subclass-specific command handlers were declared only on the relevant subclass, and Axon would figure out which aggregates could handle which commands.

Axon 3 requires all the command handlers to be declared on the superclass, which aside from breaking encapsulation means that any command that is relevant to any subclass can potentially be delivered to aggregate instances of any other subclass.

Should Duplicate Enhancement

Most helpful comment

As we are also implementing "workarounds" around abstract aggregates we are also interested in this feature.

All 7 comments

Although it was possible in Axon 2, the way to get it done was actually a workaround.
The same way should still be possible in Axon 3: simply define a number of AggregateCommandHandler beans, one for each implementation you have. They should all load aggregates from the same repository.

We'll be looking at a better way to allow proper polymorphism on entities in annotated aggregates.

Still working on this. Getting the API right to indicate a hierarchy of Aggregate, requires going through some loopholes.
Feel free to comment: https://groups.google.com/d/msg/axonframework/FhWk-OMPgZc/vmrVQ16oBgAJ
Postponing this feature for 3.3, hoping we've found a suitable API by then

This is still probably worth doing, but in our specific case, we ended up collapsing our aggregate class hierarchy (for other reasons, not due to this issue) so it's not a blocker for us to move to Axon 3 any more.

Is there an indication when this feature will be implemented? In the project I'm working on this would help reduce a lot of complexity and reduce headaches.

It'll definitely not be a part of Axon Framework release 4.2.
We'll discuss this feature, and others, again once 4.2 has been released.
We'll take your added interest into account, but I can't promise you anything time wise yet @GSamuel.

As we are also implementing "workarounds" around abstract aggregates we are also interested in this feature.

Issue #1216 and subsequently pull request #1317 will introduce Aggregate Polymorphism. This will introduce the possibility to have command handlers declared at different levels of an aggregate class' hierarchy.

In essence, #1216 was a duplicate of this issue.
Regardless, I will be closing this issue as a duplicate, since #1317 is introducing said feature to 4.3.

Feel free to keep commenting on this issue or on the other issue numbers I've just shared if you have any questions regarding this topic.

Was this page helpful?
0 / 5 - 0 ratings