Hello!
In the currently developed project, I am interested in incorporating Axon for its mature Command/Event/Query distribution capabilities. I am looking forward to giving the CQRS pattern a spin in some spots of appropriate complexity. The project as is now is not ready to migrate into Event Sourcing for data storage. And while I realise that the Query-side functionality can be implemented and stored however I please, the number of minor and major entities containing multiple interactive fields does not encourage me to implement all of the boilerplate necessary to maintain the state of both the Command Aggregate and the Query Model.
While reading the docs, namely the Axon Reference Guide, I have encountered the concept of Standard Repositories. By the guide itself "this could, depending on the type of application you are creating, be the simplest solution." And so it seems in the context of my project.
However, the system is currently running using exclusively MongoDB for persistent storage. To introduce JPA-based solution is a decision out of my scope of responsibilities. I have read the GenericJpaRepository source code and I’m left with major doubts if I understood the situation correctly. Do I re-implement all of the possible constructors in order to ensure proper operation? Should I replace the whole Repository, or would the EntityManager leading to a MongoDB based persistence be enough?
Would I find anyone willing to share a snippet of a Standard Repository implementation based on MongoDB? Numerous search results I have looked through were of no help, sadly.
Cheers!
PS. As I have forgotten to mention, version 3.4.2 being the last one with axon-mongo support I have found is the one I am currently trying to implement.
We are using Postgres for our event store. I’m pretty sure with Axon Spring Boot you could use any JPA supported persistence.
Hello Michael and thank You for an answer!
I realise that any JPA-compatible persistence should do for the case. But AFAIK, Mongo hardly fits there? I have seen some frameworks making these two work together, but it looks like an overengineering given that Mongo is a document-based solution and requires no JPA-like mapping whatsoever to function.
On another note, our Event Store is currently based on Mongo thanks to the axon-mongo package. What I’m looking for is a Standard Repository solution for our Aggregates, i.e. plain old override-on-change type of storage, not an Event Sourcing based implementation. I know this is not the pattern that Axon is empowering and while I may be able to make some drastic changes to our data-storage, this is a no-go currently.
Cheers!
For anyone out there ever struggling with the same idea - I have finally found a code sample using purely MongoDB to store the state of Aggregates in an oldfashioned way (Event-Sourcing-less).
https://github.com/Hronom/axon-gods/blob/165482bc5b/axon-gods-without-event-sourcing/src/main/java/com/github/hronom/axongods/withouteventsourcing/axon/AggregateMongoRepository.java
Shoutout to the original author of the code and cheers to anyone reading this!
Hi Szymon,
Great share on the MongoDb aggregate Repository - wasn’t aware somebody had build one!
A part from that though I’d like to add another point, regarding the Axon Framework version.
Although it is true that Axon 3.4.x is the last release which has axon-mongo in the core, it is not the latest axon-mongo release out there.
As of Axon 4, we’ve decided to move out non-core components, like axon-mongo, axon-amqp and some others.
Thus the latest mongo release can be found here, in the extensions group, with 4.0.1 as the latest release.
That’s my 2 cents.
Cheers,
Steven