So I was seeing examples I generally found online, all of which are of course Axon 4, and I was like this looks like what I’m looking for. Then I noticed the docs of Axon 5 and started looking around and I’m like “no… this is not the DDD I was looking for”; maybe it should be… Is 5 going to be flexible enough to support both mutable aggregates and immutable workflows?
First and foremost, welcome to the forum, @xenoterracide!
And I understand the concern. We’re putting a lot of value in “(event model) slice-based coding” for sure, as we see it as an amazing addition.
However, it is most certainly an addition! AF5 will still allow for the “old fashioned” aggregate approach. Furthermore, AF5 will have both mutable and immutable aggregates, a fine-tuned configuration API for non-annotation use, simplified polymorphic support, and some other nice changes.
Hence, if you are coming from a DDD-perspective and aim to keep the aggregate around, Axon Framework 5 will still be the tool for the job.
I’ll actually soon (likely next week) do a live stream wherein I’ll migrate an AF4 aggregate to an AF5 aggregate. Perhaps that might be of interest for you too.
1 Like
Sort of a question on immutable … Entities and aggregates… Records being kind of a poor choice for many reasons, mostly that they really need additional support in order to be functional like a builder if you’re going to have a large number of parameters. Since anything more than 4 parameters isn’t truly considered readable. Are libraries like immutables going to be supported? Are you considering support for mutable aggregates deprecated?
At this stage, I don’t see how Axon Framework would block libraries like that!
Then again, we don’t have dedicated tests to validate all libraries out there. In all honesty, that’s simply too much work for us to put on our plate right now.
If there’s a specific library you would like support for, be sure to give it a spin with AF5. In an ideal world, your sample would become a test case in Axon Framework 5 
No, definitely not. Although we do aim to steer users in the right direction, some flows are simply a design choice that the user of the framework needs to make. Whether your aggregate is mutable or immutable is, in my opinion, one of those things.