AxonFramework
Reorganize modules and packages
Description
Modules can be better organised so that certain applications can pull in just what they need. For example, if your application only handles queries, why wire all non-query-specific infrastructure? A similar argument can be made for a project that only exists out an Aggregate. In that case, command handling, aggregate modelling, event publication, and potentially event sourcing are needed.
To support this idea, we have constructed the modularity.md file (which can be found here).
Note that this change would require a hefty chance in the overall configuration.
Currently, the configuration module does all the configuration there is. This makes it a mandatory to pull all submodules.
Hence, before the modules can be adjusted, we should have revised our infrastructure components their configuration thoroughly.
Note that Axon Framework 4 already aimed for higher modularity by breaking apart the axon-core module in axon-messaging, axon-modelling, and axon-eventsourcing. However, this approach did not come to fruition.
While tackling this, it would be smart to take a good look at all the files and whether we think they're in the right package within a module!
Impl. Idea
As is drafted in the modularity.md, the intent is to keep the following modules in Axon Framework:
-
messaging-core-> InMemory, InProcess, Configuration, Metrics, Tracing -
event-messaging-> Configuration (archetypes), Metrics, Tracing -
command-messaging-> Configuration (archetypes), Metrics, Tracing -
query-messaging-> Configuration (archetypes), Metrics, Tracing -
messaging-> Configuration (archetypes), Metrics, Tracing -
event-sourcing-> InMemory, InProcess, Configuration, Metrics, Tracing -
annotation -
testing -
integration-testing-> unpublished
Although the original ticket dictates we remove the previous "configuration" module, the current AF5 Configuration implementation would allow for a very bare-bones axon-config module again. Note that this might be valuable to have if we provide a more detailed breakdown of AF modules.
Although the intent to remove annotations from the modules is nice, current development seems to make this option very unpractical. Especially given the existence of command, event, query, and event sourcing specific annotations. Thus, if somebody would want to only use commands, but with annotations, we would in reality need a axon-command-annotations module. This would practically multiply the amount of modules just for this.
Hence, instead, we are now leaning towards moving all reflection and annotation-based logic into dedicated reflection/annotation packages in their modules.
A lot of packages and modules have been adjusted throughout the past couple of months. The actual break down as suggested above has not taken place, however. We deemed further feature development more important for a, to be honest, working solution. Given the impending release of AF5 and the breaking changes this ticket** would incur, we move this issue to milestone 6.0.0.