Recently, I was asked on Twitter if I could give some pointers for reading material on (production) CI/CD pipelines – what they look like, and how they work. I decided to shed some light on this by describing a typical CI/CD pipeline (from my perspective), in a series of tweets. This article is an expansion of that thread.
CQRS (Command Query Responsibility Segregation) allows you to have separate models for reading and writing. Combining that pattern with Event Sourcing leads to a powerful capability: updating query (read) models, based on events. In real-time or rebuilding them from an existing collection of events. This post focuses on such projections, in applications that are built on Axon Framework.
This month an article I wrote for PHP Architect, called “CQRS & Event Sourcing in the Wild”, was published in the December 2017 “Talking Code” issue.
My article about the implications of the GDPR for event-sourced applications that I published last week generated a sizable number of responses, suggestions and comments (most of them on Twitter). All of which are appreciated of course! In this post I’ll list the most interesting comments and try to respond to them.
As my flight touched down at Schiphol Airport early this morning, I realized that that landing marks the closing of my 2017 conference season.
In a previous article, I wrote a few things about upcasters. One of the significant downsides when implementing an upcaster is that it adds to our application’s technical debt. An alternative technique is the versioned event store (or versioned event stream), where the existing event store is copied and modified. In this post I’ll discuss the pros and cons of both approaches.
In May 2018, a new piece of EU legislation called the General Data Protection Regulation (GDPR) will come into effect. The GDPR attempts to regulate data protection for individuals within the EU and has very interesting and specific implications for applications that use event sourcing. In this article, I’ll discuss my thoughts on this subject and a few pointers for those implications.
Replaying events is a crucial part in any event sourcing / cqrs application, to rebuild projections, generate new ones or seed external systems with data.
I’m a big fan of the Axon Framework. Even with its quirks and occasional (strange) bugs, it’s my go-to toolbox for my event sourcing & cqrs consulting and development work.
With the recent 3.0 release, Axon changed the way events can be replayed by introducing the Subscribing and Tracking event processors. The Subscribing processor follows the event stream in real-time, whereas the Tracking processor keeps track of events it has processed (using a token). This means that the Tracking processor can be stopped and resumed, and it will pick up processing where it left off.
One of the things I love about Java is its native, compiler-level support for annotations, a form of syntactic metadata which can be applied to source code but also retain at run-time to influence application behavior. I use them almost daily in my projects.
I do a fair amount of consulting and development on event sourced applications and these usually use Axon, a popular CQRS & event sourcing framework. Recently, Axon version 3 was released, supporting a number of annotations that can turn any POJO (Plain Old Java Object) into an event-sourced aggregate.
The 2017 version of Puppet’s State of DevOps Report was just released.
To me, the most interesting takeaways from the report are:
- High performing teams have 46x more frequent deploys, 96x faster mean time to recover/repair and a 5x lower change failure rate.
- They also automate significantly more work (automation is a key ingredient of any successful DevOps strategy).
- A lower change failure rate and significant automation mean these teams spend 44% more time on new work (and 26% less time on unplanned work and rework).
- Developers in high performing teams generally work in small batches and practice Trunk Based Development. Low performing teams on the other hand use long-lived feature branches and merge infrequently to trunk or master (read on for my thoughts about feature branches).