Any plans to decouple AggrateRoot from pre-set JPA field names?

Hi,

I’m currently investigating the possibilities to move our CRUD system over to a CQRS based system. In order to have as less impact as possible, I don’t do ES yet. So my repository implementations are directly mapping the AggregateRoot to MySQL datasource using RowMappers. In order to be compliant with the AR contract, I need to provide fields deleted and version as well. However these fields are not settable and the AbstractAggregateRoot contains directly JPA-field dependencies like @Transient, @Basic. But what if you don’t use JPA at all? I wish there was a less JPA-dependent AbstractAggregateRoot implementation, containing some constructor fields for the values deleted and version…

Is something on the roadmap for this?

Hi,

note that even though there are JPA annotations, that doesn’t mean you need JPA on your classpath. Java will simply ignore annotations on classes that are not available in the classloader.

The deleted field is made transient, because you don’t need to store it. That field is used to tell the repository that an aggregate should be deleted on “save”.
The fact that the version field is private an not accessible in subclasses is unfortunate. A workaround would be to use reflection to set the value.

Axon 3 will have a redesign of the classes. The abstract classes will not contain any persistence information, to make it more compatible with non-JPA persistence models.

Cheers,

Allard

Version 3… That sounds promising! Do you have any idea about when it will be available?

Hi,

we’re currently working hard on 3.0. We expect to be able to release it in Q1 of 2016. Watch this mailinglist, as we’ll make an official announcement once we have a delivery date.

Cheers,

Allard