This is a question related to practicality… as the design of few iterations is when things to be more domain oriented (as read in Eric Evans Book).
Basic any good design comes from some iterations of refactoring.
I have a major refactor design decision and questions on this with Axon apps. Unfortunately good design comes from major refactors and with persisted data in production is becoming a challenge with non traditional sql table type infrastructure with heavy serialization usage.
- changing of packaging names, Class names and hierarchy structures of aggregates, sagas, command apis and Events i.e. Best practice for how to handle movement of package hierarchies, spilt jars for physical componentization and evolve a better design with data persisted in production for current version.
This typically occurs when new bounded contexts appear after some design has been rolled out and refactoring is required or extraction of framework patterns also for better abstraction and better dependency design.
Changing of Event name and attributes i.e. adding and removing fields in addition to changing name or package structure.
For query side also, JPA should be easier as there are no namespace conflicts. One of the challenges is that we have serialized object heirarchy with JPA and changing those signatures of package hierarchies and the package name changes could be a major challenge, nothing to do with Axon, but any thoughts on best practice on how to refactor.
Was thinking through this before doing some refactoring, however am trying to qualifying any challenges with existing data persisted in Event Store and Saga Persistance along with Query DB.
Appreciate any thoughts and what others have experienced learned on these topics.
Thanks and Cheers…