I have seen two primary approaches to building a audit trails for systems – entity level audits and property level audits.
Entity level audit maintains an audit log for every entity and makes an audit entry for ‘any’ operation done on these entities. Weather there is a change in one property of the entity or the entire entity changes as part of an operation that affects a bunch of other entities in the same transaction. At database level, this is often implemented using triggers that would copy the row being changed to an audit table along with some audit information.
Property level audit, on the other hand, goes to a different extreme and makes an audit entry every time any property on any entities changes. At database level this often translates into one big fat table which keeps track of any field in any table that has changed along with some general audit information.
Whiles these are two widely adopted implementation approaches for performing system audits, what both of these approaches fail to capture is the actual intent of the user. The granularity at which the system captures the audit data has an impedance mismatch with the business and it can get difficult to tell what actually was done to system to create this audit entry. Hence, these audit data would have a very limited business meaning and use.
Think about a modelling strategy where the actual operations that can be performed on the system are expressed explicitly. Wouldn’t it be a lot easier to just record these operations or the fact that these operations got performed on the system? This kind of audit data would have the granularity that would make sense to the business and creating a business meaningful audit reports out of such audit logs would be a lot easier. Isn’t it?