CQRS stands for _Command-Query Segregation Principle_. Greg Young described (and named) the pattern thoroughly in 2010, but the idea existed way before that time
Event Sourcing is an alternative way to persist data. In contrast with state-oriented persistence that only keeps the latest version of the entity state, Event Sourcing stores each state mutation as a separate record called an event.
Event Sourcing can bring your business a lot of benefits, but how do you convince senior staff that it's worth it?
During this webinar, you'll learn some patterns and anti-patterns of read models and get more piratical tips about implementing projections with Event Store subscriptions. We will also discuss eventual consistency in more detail and answer the most frequent questions about it.
We are going a little beyond the very basics of Event Sourcing and will start implementing an application that uses the CQRS pattern. During the webinar, Alexey will introduce the CQRS concept and will demonstrate why CQRS is important in event-sourced systems. There will be a great deal of live coding again, demonstrating all the moving parts of both command and query sides in a real-life, although simplistic, application with a domain model.
We are running a free webinar titled Introduction to Event Sourcing. It's a practical introduction for developers and architects who are new to Event Sourcing and are interested in seeing how to convert business requirements into an event-sourced application.
Event Sourcing is relatively new to the financial services industry. By implementing Event Store’s approach to support its digital transformation strategy, Linedata can be more responsive to the changing needs of its customers and gain a competitive edge in the market. “The core benefits of event-driven architecture allowed us to improve quality, performance and respond quickly to our customers,” said Adrian Tovey, who leads Linedata’s global program management. “Event Store has helped us meet the demand for change in the industry, a change in the way applications are used to deliver services to our customers; Linedata is at the forefront of those changes.”
Last week on a call with someone the question came up about the Event Store about why can they not update and event and how should they handle the case where they need to. The conversation that came out of this was very rich in architectural insight into how the event store works as well as overall Event Sourcing understanding so I thought that it would be worth spending a bit of time to write...
In the last post we introduced the new concept of fromStreams() that will join multiple streams into a single stream for your fold to be run against. We also introduced options and two options that can be used to control the re-ordering behaviour in a distributed environment. In this post we are going to look at how this concept is used internally in the Event Store in order to provide indexing of queries. Let’s propose...
Up until this point we have only used two event selection methods for our projections. We have used fromStream(‘stream’) which will select all of the events in a stream and we have used fromAll() which selects all events in the system. There is another quite useful selection that will move us from SEP (Simple Event Processing) to CEP (Complex Event Processing). This is the ability to select between multiple streams. To select from multiple streams...