JPA alternatives

Axon Framework
1

Hi,

Is Axon planning any alternatives for ‘aggregate state’ storage in the near future?
Currently, the only option is JPA.

There’s also Event Sourcing for ‘event state’ storage.
While Event Sourcing has many benefits, not all use-cases require ES.

Then the only option that remains is JPA.

While JPA is not bad at all, I think that JPA should not be a part of the domain model.
When applying ports & adapters, JPA should be only known in an adapter.
I think that it should be possible to have a separate domain and persistence model.

In my opinion, JPA just doesn’t fully solve the impedance mismatch.

So I think that it might beneficial that Axon Framework provides some alternatives like:

  • still use JPA but only in an adapter (requires some manual mapping between JPA entity & Aggregate)
  • leave the ORM path and provide plain JDBC operations like libraries as Spring Data JDBC & JOOQ.
  • provide NoSQL alternative

Any idea to provide such thing in the near future?

2

Hi @Bram!

Welcome to the forum and great to see your first thread landing here.

As you’ve noted correctly, Axon currently provides two aggregate Repository implementations:

  1. EventSourcingRepository (note: there also is a CachingEventSourcingRepository)
  2. GenericJpaRepository

You might already have checked our issue tracker on GitHub on the matter. As it stands, we don’t have any plans to provide a new type of Repository implementation.

Nonetheless, we are always open to suggestions. Both in the form of issues created on the previously mentioned GitHub repository, or even taking it a step further with a pull request.

Concerning myself, you are the first I’ve heard the desire of a different storage solution for aggregates. The desire to be annotation-less in your model is however certainly not new. This shift is not present on the issue tracker, but I can ascertain you we are thinking of solutions which would completely remove any framework-specific things from within the Domain Model. However, this is easier said than done of course.

Having said all this, I hope it is clear we are open to any suggestions you might have. I’d like to ask you to create an issue for the exact thing you’d prefer most. Having that issue in place is the biggest assurance you can have that, somewhere in the future, we’d have another Repository implementation.