Non-Generic JPAEventStore?

Hi all,

I currently have a customer that strongly dislikes the storage of
domain events in a serialized form.

Has someone tried storing domain events in a relational fashion (one
or more tables per domain event)? What I mean is a kind of customer
EventStore that stores the events in a special event database. It
should be possible to configure every event as JPA @Entity and persist
it that way in a DB.

I know this requires always creating at least one database table per
new event but it may have also some benefits.

What do you think?


Hi Michael,

it’s a concept that has crossed my mind a few times in the past. However, I’m not a proponent myself.

The first thing I wonder about is the reason why the customer dislikes it. Does it have to do purely with maintenance, operational support, etc? I regularly inspect the JpaEventStore using SQL Tools for a project in production (just to prove that really a user did something wrong). I found it reasonably easy to find whatever I was looking for. It’s something you can easily get used to.

I also think it severely impacts performance to spread events around in multiple tables. Although, I have to admit, in most applications, read performance is generally not an issue.




The first thing I wonder about is the reason why the customer dislikes it.

I guess it's mainly because the database admins don't like
unstructured XML BLOB data they can't control... :wink:


Would be interesting to compare standard event serialization with
something like Hibernate's "Table per subclass" inheritance strategy.

However... I'm still in the process to convince them CQRS/Event
Sourcing is the right way to go - But most Architects and Decision
Makers haven't even heard of CQRS... <sigh>


sigh… just wondering when the dba’s will finally learn that they do not own the data that’s stored in “their” databases… I’ve even heard of DBA’s that refuse “denormalized” data models… pfff.

If there is anything I can do to help you convince then, don’t hesitate to ask. Otherwise, you could try to send them to my workshop :wink:

I’ll think about other ways to store the events in the meantime. Personally, I think there is a better match with document databases than schema-based db’s, but let’s give it a try.