InfoQ Homepage Event Driven Architecture Content on InfoQ
-
Start with Events and DDD When Building Microservices
Domain-Driven Design (DDD) is a great technique bringing designs closer to the domains we are working in, but too often we make early decisions with a focus on structure, which is not the intention of DDD. Instead we should start with the events in a domain, Russ Miles claims when describing the advantages of going “events-first” when building microservices.
-
Microsoft Open-Sources P Language for Safe Async Event-Driven Programming
Microsoft’s recently open-sourced P language aims to make it possible to write safe asynchronous event-driven programs on Linux, macOS, and Windows.
-
Vaughn Vernon on Microservices and Domain-Driven Design
Although a monolith can be modeled in a respectable way, often they are turned into a big ball of mud. This is caused by multiple domain models becoming entangled within the monolith, and in Vaughn Vernon's experience this can happen within a few weeks or months, he claimed in a presentation at the Scala Days conference earlier this year.
-
Comparison of Event Sourcing with Stream Processing
Event sourcing and CQRS are two patterns that has emerged in the Domain-Driven Design (DDD) community. Stream processing builds on similar ideas but has emerged in a different community, Martin Kleppmann noted in his presentation at the Domain-Driven Design Europe conference earlier this year comparing event sourcing with stream processing.
-
A Whole System Based on Event Sourcing is an Anti-Pattern
Command Query Responsibility Segregation (CQRS) was never meant to be the end goal of what we are trying to achieve, it is a stepping stone towards the ideas of Event sourcing, Greg Young stated in his presentation at the Domain-Driven Design Europe conference earlier this year. He noted though that just applying CQRS is still a valuable pattern.
-
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.