Aggregate fixture hierarchy behaviour about axonframework

[smcvb]

Thanks for filing this concern with us, @stephan-strate.
I'll take a look at what is amiss with the AggregateTestFixture.

I may come with follow-up questions later on, so stay tuned!

[smcvb]

Ah, alright, I am pretty sure I have found the predicament. Luckily, it's straightforward.

The reason the FixtureTest_Hierarchy test fails if you move the @CommandHandler annotated method to the concrete aggregate i.o. the abstract aggregate, is because the AggregateTestFixture is constructed based on the AbstractAggregate.
If you base the AggregateTestFixture on the ConcreteAggregate instead, the test succeeds as expected.

Furthermore, doing so aligns with Axon Framework's wiring logic.
If you configure aggregate through the AggregateConfigurer, you're also required to provide the concrete type, not any of the abstract classes.
In a Spring environment, the scenario would be the same, although Axon Framework will look up the concrete type(s) for you, based on the @Aggregate annotation.

With that, I am pretty comfortable with closing this issue as resolved.
If I have missed anything obvious or you still have questions, @stephan-strate, be sure to reach out!

[stephan-strate]

Sure, this works. But it seems like the fixture should be able to find all @CommandHandler when configuring it like this:

val fixture = AggregateTestFixture(AbstractAggregate::class.java)
    .withSubtypes(ConcreteAggregateA::class.java, ConcreteAggregateB::class.java)
    .registerAggregateFactory(object : AggregateFactory<AbstractAggregate> {
        // resolve aggregate type by event
    })

[smcvb]

Can you explain why do you think the fixture should be able to deal with ingestion of the abstract type instead of the concrete type, @stephan-strate?
Is that because the code is as it is right now?
Or do you feel the JavaDoc is lacking?

As stated above, Axon Framework production code does not use the abstract type for aggregate registration. Ever.
As such, the fixture should neither. Instead, it should follow the approach taken in production to register an aggregate.

Hence why I am asking why you feel differently. Perhaps I am missing something obvious here.

[stephan-strate]

Hmm, maybe I am mistaken. Sure in production it might have the concrete type. In test it does as well, resolved by the AggregateFactory.

I mean in production I do register the abstract aggregate with it subtypes as well, right?

[smcvb]

Ah, gotcha! There is a slight, but conceptual difference between the FixtureTest_Hierarchy and the Polymorphic Aggregate support.

The FixtureTest_Hierarchy was constructed as part of supporting hierarchical aggregates (somewhere in 2015) with just one concrete type.
With this feature introduction, the AggregateTestFixture didn't have to alter nor did the Framework impose any constraints on how the parent and concrete types look.

Polymorphic aggregates where introduced more recent (2019 if I recall correctly), which did imply API changes for the user.
For one, when registering an aggregate, you are inclined to provide both the root type as well as the concrete types.
For the AggregateConfigurer and AggregateTestFixture that's the withSubtypes(Class...) method, for example.
In a Spring environment, users are inclined to add the @Aggregate annotation to the root and the children (so that Axon Framework can find the whole "tree").

Furthermore, and more importantly for the FixtureTest_Hierarchy test case, is that a polymorphic aggregate is not allowed to have a constructor on the root.
However, the FixtureTest_Hierarchy.AbstractAggregate has a constructor, whereas the FixtureTest_Hierarchy.ConcreteAggregate does not.
As such, it does not comply with the required polymorphic-aggregate format, but with the "old-fashioned" hierarchical aggregate format.

If you adjust the FixtureTest_Hierarchy by using the withSubtypes method, remove the AbstractAggregate constructor, and by adding a command handling constructor to the ConcreteAggregate, the test succeeds.

I hope all the above explains the current setup, @stephan-strate!
And one question remains: do you think we need to adjust documentation/javadoc somewhere to make this more apparent?