InfoQ Homepage Event Driven Architecture Content on InfoQ
-
Moving from Transactions to Streams to Gain Consistency
With many databases in a system they are rarely independent from each other, instead pieces of the same data are stored in many of them. Using transactions to keep everything in sync is a fragile solution. Working with a stream of changes in the order they are created is a much simpler and more resilient solution, Martin Kleppmann stated in his presentation at the recent QCon London conference.
-
CQRS Example Using Axon Framework
Command Query Responsibility Segregation (CQRS) separates the part that changes the state from the part that queries the state in an application. Axon is a Java framework implementing the building blocks of CQRS to help in when building CQRS applications, Dadepo Aderemi, writes in a series of blog post explaining CQRS by building a small demo application based on the Axon Framework.
-
CQRS, Read Models and Persistence
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.
-
Introducing Reactive Streams
Modern software increasingly operates on data in near real-time. There is business value in sub-second responses to changing information and stream processing is one way to help turn data into knowledge as fast as possible, Kevin Webber explains in an introduction to Reactive Streams.
-
Domain Events and Eventual Consistency
Eventual consistency is a design approach for improving scalability and performance. Domain events, a tactical element in Domain-Driven Design (DDD), can help in facilitating eventual consistency, Florin Preda and Mike Mogosanu writes in separate blog posts, each describing the advantages achievable.
-
Dino Esposito on CQRS, Messages and Events
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.
-
A Critical Look at CQRS
Looking at Command Query Responsibility Segregation (CQRS) in a larger architectural context there are other architectural styles available. There are database technologies solving the same problems but in a simpler way, Udi Dahan states looking into ways of approaching CQRS. There is also a way that fulfils a lot of the CQRS goals but with fewer moving parts when CQRS is really needed.
-
DDD, Events and Microservices
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.
-
Introducing CQRS and Event Sourcing with a Demo Application
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.
-
Advantages of CQRS
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.
-
A Service is a Logical Construct Built by Microservices
A service is a logical construct owning a business capability and made up of internal autonomous components or microservices that together fulfil the responsibilities of the service, Jeppe Cramon suggests continuing a previous series of blog posts clarifying his view on building services around business capabilities and bounded contexts.
-
Making Sense of Event Stream Processing
Structuring data as a stream of events is an idea appearing in many areas and is the ideal way of storing data. Aggregating a read model from these events is an ideal way to present data to a user, Martin Kleppmann claims explains when describing the fundamental ideas behind Stream Processing, Event Sourcing and Complex Event Processing (CEP).
-
The Future of Microservices
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.
-
Sharing Data Between Bounded Contexts in Domain-Driven Design
When using Domain-Driven Design (DDD) separating the concerns of a large system into bounded contexts with each context using its own data store there is often a need to share some common data. One way of doing that is to let each context publish events about changes, events that others can listen to, Julie Lerman recently explained in MSDN Magazine.
-
CQRS as a Style of Thinking
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.