The claims here are factually accurate and helpful for people new to using event sourcing as a pattern. The pattern does lend itself very neatly to command query responsibility segregation with eventually consistent reads (except when reading just the last or all events). In addition, while the pattern itself wouldn't qualify as a systems or platform architecture, if the API for the system is designed to capture customer intent on the write side and read its side-effects on the read side, you can see how it all comes together in a neat architecture that not only allows the ability to reason about the system, it also mirrors and meets the needs of its callers/customers automatically because the API is simply a capture of customer's intent. And because the customer's intent (commands) and its outcomes (events) are immutable, you also get automatic change management even if the code continues to evolve and new features added.
No comments yet.