The reasons for choosing an architecture can be so varied. We take into account customer needs, stakeholder requirements, legislation and non-functional requirements like availability and security.
At its core though, choosing an architecture is about choosing what you optimise for and the best choice, in the long run, is to optimise for change.
Event Sourcing is pretty popular right now and one reason I hear for choosing it is auditability, βif we have a log of all the events of changes in the system, we get auditability for free!β
I think this is a bad reason to choose Event Sourcing - youβre choosing a particularly difficult pattern, simply so you can check what the system has done in the past.
Why it might not provide auditability
Itβs possible, and probable, you wonβt get Event Sourcing right the first time, and whoβs to say you actually have recorded all the events of the system? If youβre not testing your golden source of truth regularly then you may not have all your data in events and therefore your audit trail may not be complete.
Why you should really choose Event Sourcing
A good reason to choose Event Sourcing is that you donβt know your future requirements. No one can fully predict how a system will evolve or what will be needed a year from now. Having a stream of events of all the previous changes which can be read from any service allows you to be flexible and implement any future requirement - itβs truly extensible. This is because any requirement can be implemented as a new service and it can load in data, transforming it and enriching it to meet whatβs needed. For example, a requirement to send email reminders to fill in some questions: a new service can now consume user events to get email addresses and names, along with the events about when they last filled in the questions. The new service builds up an understanding of the current state of the system and then uses that to make decisions. This is all possible without changing the existing services, which helps to reduce the chance of introducing regressions, and makes it simpler to deploy since the change is only adding services, not modifying any.
In this way, Event Sourcing optimises for dealing with change in requirements.
Top comments (0)