We tried to modify the sample application that has been posted by
Allard Buijze on the JTeam weblog in order to get rid of the event
sourcing part (as an exercise for our application, where it is not
needed).
We noticed that by implementing Axon's GenericJpaRepository we had to
use JPA annotations in our domain model on the command side, thereby
loosing our much appreciated persistence ignorance. Isn't it much more
preferable to serialize the current state of the aggregate root with
XStream instead and storing it in a table by aggregate root ID? This
way you don't have the burden of event sourcing but may still reap the
benefits of persistence ignorance. Of course, the event handlers still
remain in control of updating the views on the query side.
what you say is true. But it is JPA that actually removes the persistence ignorance from the domain model. Unless you use Hibernate, when you can still use the hibernate XML mapping files, if you like. Personally, I don’t mind a few JPA annotations on a domain class.
Storing a serialized version of the aggregate is definitely a possibility. I was planning to build a “Hybrid” Repository that stores both the actual state as well as the new events. The state is used for reading the aggregate back in, the events for future reference, auditing, etc. By removing the “append event” part of this repository, you practically have the repository that you’re referring to.
Do take into account, however, that aggregates will need to be serializable. Maybe not in the Java interface sense of the word, but still.
Anyway, I’ll create some issues describing these ideas shortly. Thanks for you feedback.
We don't mind a few JPA annotations on a domain class either, but
sometimes you are forced to compromise your domain model to be able to
persist it. For example consider a class that contains a one to one
relation with an interface. Suppose this interface has 2
implementations. This implies that we have to create an abstract class
which the implementations need to extend, just to be able to make the
mapping. The sole reason for this abstract base class is then the
mapping and compromises our domain model. The difficulty of finding a
right name for such an abstract class only underscores this.
To our opinion this is the most important reason to keep persistence
ignorance than the persistency related annotations.