Yesterday an article was posted on Wired about code quality. The first part of the article is a fantastic and accessible explanation about what happens to applications when the underlying code is poor quality. If you wonder why code quality is important, read that and see if you’d like that to be a description of a program you rely on.
The article then goes on to recommend a solution, Event Sourcing, to the problem of code which has become an incomprehensible tangle of dependencies.
First though, I must say, there is no one best way to write code. There are many wrong ways to do it. The right solution is the one that meets the needs of the users and stakeholders and is flexible enough to be changed as those needs change.
Event Sourcing, as I understand it, consists of three main principles.
- Announce events as they happen.
- Store the events.
- State is a result of applying events in order.
An event driven architecture, also sometimes called Pub-Sub (publication-subscriber), is a proven way of breaking dependency between parts of a system. Operations that don’t require a response (there are many more of these than you might imagine) are announced instead of being processed immediately. Listener(s) passively receive notification of the event and the details of the event which they then process.
Not only does this make performance appear better to the end user, but it also allows discrete parts of the system to work together without knowing anything about each other.
Storing the events after they’ve been processed isn’t unusual either, at least for a period of time for auditing purposes. Debugging an event driven architecture isn’t as simple as debugging an imperative program.
The interesting part of this design is that state isn’t stored, only the events. When state is needed it’s assembled by replaying all of the events back in order. Not having any experience implementing this design, I’ll withhold judgement (and recommendation), but I do wonder about performance as the amount of data increases. Every design has it’s strengths and weaknesses.
Most of the benefit of breaking dependencies in this design come from the use of events, not from the use of events as a storage of application state.