The reality of modern application design means that when an unexpected issue occurs, the ability to find the root cause can be difficult. This is where the concept of centralized log management can provide a great deal of assistance. This Refcard teaches you the basic flow of a log management process, provides a comprehensive checklist of questions to consider when evaluating log management solutions, advises you on what you should and should not log, and covers advanced functionality for log management.
The Oxford Dictionary defines ‘Data’ as: “Facts … collected together”. Should we instead use the specialized language of application architects, ‘Data’ can be more accurately defined as: ‘Events folded together’. ‘Folding’ represents the act of merging a particular Entity’s (State-changing) Events, in chronological order, to compute the latest Entity ‘State’ — what we typically refer to today as a Data 'Record'. Data — unlike Events — is an abstract notion. Whilst ‘Events’ represent actual changes to an Entity’s State (e.g. PurchaseOrder.Deleted), ‘Data’ represents no more than the calculated State of a particular Entity, once all preceding Events have been folded together; something that cannot even be performed should you ever lose any Events.
At some point in history it was decided — clearly owing to restrictive hardware costs at the time — that we could not possibly store all State-changing ‘Events’ in our Data-bases, but that instead, we could only store ‘Data’: the current ‘Folded State’ of each business Entity (until such a time as even that was archived, owing to archaic hardware constraints).
