Auditing - Letting a user see who did what to an entity


[ Open issue might apply here. ]

I’m considering Lagom/Cassandra for a rewrite of an existing RDBMS-based application.

One of the common themes in the existing application is that when an Entity is changed, information of What was changed an by Whom is written (variously to that Entity, or to a separate audit table).

Since an event-sourcing model would be taking Commands and generating Events, from which PersistentEntity state is constructed, is it feasible to peek into the Event stream of a PersistentEntity and perhaps, if requested, to reconstruct the PersistentEntity as-it-was after a particular event?

This generic capability would mean that I could completely ignore “Auditing” from a modelling perspective, and generically satisfy that requirement directly from the Write-side.

Many thanks, Robin.

I personally don’t think this is a good idea. Unless your entity is modeling audit itself.
Your entity should only holds that about the domain it’s modelling. Auditing is a orthogonal concern.

You can however add metadata to your events (eg: userId). That information should not be kept on the entity, unless there is a direct usage for the model in question.

Then, you should use a read-side processor to generate the audits. And if you want to generate an audit up to a given point in type, you can consume the events directly using akka-persistence-query API. You can select all the events for a given persistenceId and consume them up to the point you want.



Thanks Renato,

I agree that Auditing is Orthogonal to the domain model (persistent entities). I would happily sacrifice the “Who” if I could get an ordered list of Events to render, but surely this could come from the Write side?

I perceive the Read side as maintaining a representation of current state, not historical. Adding Audit into the Read side would appear to complicate everything, require modelling of Audit, and make it part of the domain model.

And what if there is no Read-side at all (entities are known by their keys and not flexibly searchable)?

Kind regards, Robin.

I think a better way to view the read side is that it represents some meaningful view of the events for your use case. Keep in mind that you can have more than one read side view for a given entity type. It’s often a good idea to have multiple representations, for different use cases. This is one of the benefits of CQRS!

That said, there are ways to query the write side by persistence ID that might suit your needs. You’ll need to use underlying Akka Persistence Query APIs, as @octonato mentioned above:

Tom / Renato,

I really like the idea of considering Auditing as being just another Read-side, orthogonal to the “normal” Read-side.

Thanks, Robin.