Storing events in a relational database and creating the event identity as a globally unique and sequentially increasing number is an important and maybe uncommon decision when working with an event-sourced Command Query Responsibility Segregation (CQRS) system Konrad Garus writes in three blog posts describing his experiences from a recent project building a system of relatively low scale.
Command Query Responsibility Segregation (CQRS) is the starting point of a change that will have a profound impact on system architecture, Dino Esposito claims in three articles in MSDN Magazine. It’s the first step in an evolution transitioning software architects from the idea of “models-to-persist” to the idea of “events-to-log” and about event-based data instead of data snapshots.
To make microservices awesome Domain-Driven Design (DDD) is needed, the same mistakes made 5-10 years ago and solved by DDD are made again in the context of microservices, David Dawson claimed in his presentation at this year’s DDD Exchange conference in London.
Improving on his understanding of the architecture and patterns involved in Command Query Responsibility Segregation (CQRS), Sacha Barber has created a complete CQRS demo application including event sourcing and an article with a cross examination of the inner workings.
Today’s applications are commonly unnecessarily complex or slow because of not using Command Query Responsibility Segregation (CQRS), Gabriel Schenker claims while stating he believes CQRS to be one of the most useful architectural patterns when used in the context of complex Line of Business (LOB) applications.
Microservices are not new ideas and we will over the course of 3-5 years end up rebuilding WS-* the same way Web Services did rebuild all from CORBA unless we learn from our mistakes and improve to prevent them from being made again, Greg Young stated in a presentation at the Microservices Conference in London.
A common context for Command-Query Responsibility Segregation (CQRS) is a collaborative domain with multiple users working on the same set of data, it is less suitable in domains with only a single user working on a piece of data, Udi Dahan explained when discussing CQRS in an interview.
State transitions are an important part of our problem space and should be modelled within our domain, Greg Young states in a recent presentation focusing on basic event sourcing and how CQRS fits in.
CQRS and Event Sourcing provide a clear and concise way to build distributed applications that adhere to the reactive manifesto, Duncan DeVore claimed in a recent presentation sharing his experiences building a distributed application using Akka and Scala.
DDD and CQRS are great for building scalable software considering concepts like bounded contexts, transaction boundaries and event based communication and is together with Akka a complete platform for building enterprise applications, Pawel Kaczor starts a three-part series building an reactive application based on these concepts.
Delay of message sending into the future is a very powerful pattern and is often the preferable way of dealing with temporal problems compared to batch job that will run a query on the domain model and update some aggregates, Greg Young explained at the recent DDD Exchange conference in London.
Version 2.1 of CQRS framework Axon supports annotations and ordering of event handlers, a new conflict resolution together with performance improvements. The recently released version also adds compatibility with OSGi.
Complex Event Processing, CEP, can be very useful for problems that have to do with time e.g. querying over historical data when you want to correlate things that have happened at different times, Greg Young explained in a recent presentation.
Version 2.0 of the Event Store, (an Event Source based persistence engine), was released last week with support for security, allowing for lock down of the Event Store and setting up Access Control Lists on event streams. The Projections library is now in beta and more documentation has been added.
Not all systems are based on events or facts. In some problem spaces events make complete sense; they are about facts that are happening over periods of time. But a lot of systems are instead focused on information that flow through a process, Greg Young explained at DDD Exchange Day in London last week, using handling of a mortgage application inside a bank as an example.