Event Sourcing is good for you

When you consider Domain-Driven Design when building systems and applications, you might be wondering why should you even consider using Event Sourcing? Is it because the original name of Event Sourcing was "Distributed DDD", and "DDD/ES/CQRS" became somewhat a classic set of acronyms? In fact, when you read an event sourcing-oriented article from a vendor like Confluent or Amazon AWS, you find little connection between what they mean by "Event Sourcing" and Domain-Driven Design.

It looks like the connection between DDD and Event Sourcing is getting lost at times. However, I still believe that Event Sourcing has lots of benefits when being used to build a system following the DDD principles. I will share some of the key points that make this synergy obvious and appealing during this talk. I'll also tell some stories from the field when developers gained so much from parts of the systems they built being event-sourced that they can hardly imagine doing anything else.

More Dev, less Ops - faster delivery for .NET Core apps with Kubernetes and GitLab

Developers like to create new software, but until we deliver the software to production, it creates no value. Traditionally, we tend to set up cumbersome CI/CD pipelines using numerous tools; we follow complex processes like GitFlow; our QA people still test everything in a staging environment.

Containers promised us a whole new world, where we can have predictable environments and can compose tools in sets, create new environments fast and easy. To make it work, orchestrators appeared and finally, we found ourselves in a world of even more complexity around tools, configuration file, and operational concerns. Some have dropped the idea of using containers in production entirely, some struggle building an effective delivery pipeline.

We need to have seamless experience and tooling that allows us to go from the idea to code, from code to container images, from images to deployment. We need a proper feedback cycle with pull requests, code reviews, and testing for each feature in isolation. Several tools might help us to achieve this goal, and the one that got closest to the promised land is GitLab.

During this talk, we will create a .NET application with WebAPI and set up the delivery pipeline with GitLab and Kubernetes. We will be able to deploy our app to staging and production environment and even have separate “review” environments for each merge request, where testers can go and test the application for each separate change.

DDD, Event Sourcing and Actors

Event sourcing is not new - the prase that you can hear on most of the talks delivered by Greg Young, the “father” of CQRS. People were using ledgers to ensure the correctness of their record for ages. Suddenly, this pattern got popular, when developers for infrastructure components to store pieces of data in what we now call streams of events. Larger players like Netflix started to share their stories with this technique and that definitely spiked the interest among the community.
With this spike, tons of questions came up. Does an event-sourced system need to be eventually consistent? Are we making decisions on stale data? What to do with users that panic when they don’t see something that they have just created, or updated, on the application screen, because the read-model hasn’t been updated yet? How to solve race conditions on the write-side? Can we use a message broker for projections? How in this world can we scale projections, if events must come in order? Finally, nearly all Actor Model frameworks have streams and event-sourcing built-in, for what purpose?
A lot of confusion lead to a lot of failed attempts to use this brilliant pattern, a lot of angry articles from good developers that tried and failed. So, is event-sourcing is just another hype and in reality its complexity and all those issues associated with it overweight potential benefits?
Let me show you how I implement Event Sourcing in real-life projects as part of my daily work. We start by looking at a very simple, yet properly working event-sourced application, which is built with Domain-Driven Design principles in mind. Then, we look at some of those issues that are mentioned above and see how they can be solved. Finally, we get a quick look at how actors fit in all of this and when we might consider using the Actor Model for an event-sourced system, and how it can be done in code.
There will be a lot of C# code in this talk. I will use EventStore as the persistence and Proto Actor to show how to use the Actor Model.

There will be a lot of C# code in this talk. I will use EventStore as the persistence and Proto Actor to show how to use the Actor Model.

Hands-on Event Sourcing with C#

Event-sourcing remains a hot topic in the industry, it enables a lot of possibilities to build reactive microservices that scale and collect a lot of useful data. In particular, whilst DDD is convincing developers to make the behaviour a first-class citizen in their models, only event-sourcing actually allows us to persist the behaviour just as we used to persist the state of our systems.

However, many warn about technical complexity and challenges on this path. We keep reading stories of people who got excited with the pattern and then failed due to continuously increasing technical complexity, issues with the eventual consistency, decisions made by the business logic based on stale data, frustrated users that don't see their own updates, the list goes on. With the recent spike of interest, the lack of real-life success stories is apparent. Perhaps overly optimistically, we can claim that all those issues that are described in the majority of articles about the "dark side of the event sourcing", are solved problems and we are ready to share our experience with you.

During this session, you will learn how to work with event-sourced aggregates and use an event store, how to separate infrastructure concerns from your domain model, how to build projections and many other practical aspects. Stories from the field will be delivered as a bonus.

Simplicity vs Simplification

Software industry developed strong preference towards simplification. We have important principles like KISS and YAGNI in our toolbox. We keep hearing "stop over-engineering" from leading experts in the industry. But we must not forget the distinction between essential and accidental complexity. A number of biases, completely natural for human brain, are effectively lead us to over-simplify problems we are working. Many of the UI and UX issues we around us are caused by intolerable level of ignorance, demonstrated by people who created those products and solutions. The only efficient way to fight this tendency is to realise and embrace the complexity. This talk will focus on demonstrating the issue and providing advise on engaging our cognitive abilities in order to solve complex problems.

Real-life Event Sourcing

Join Alexey Zimarev, the Event Sourcing enthusiast, author of "Hands-On Domain-Driven Design with .NET Core" book, and creator of Eventuous, for a two days workshop for developers and architects who are willing to learn practical aspects of implementing Event Sourcing in production systems in .NET ecosystem.

Today, many of us already heard about Event Sourcing and its benefits. However, when it comes to writing code, it could be quite challenging to start from an empty screen in the IDE. Using one of the Event Sourcing frameworks that promise to deliver everything out-of-the-box might be helpful at the beginning but also bring a great deal of "magic" to the system and hides a lot of important implementation details.

During this day we will model and build an application using tactical patterns of DDD with CQRS and polyglot persistence. We will start with a quick modelling session to find out how the new system can be represented in a loop of commands, events and read-models. Then, during the course of the implementation exercise, we will create a set of useful abstractions and tools that you could continue to develop further and use in your projects.

Topics covered:
- Modelling with domain events
- A whiteboard that compiles - convert sticky notes to code
- Commands, events and consistency boundaries
- Persistence for events
- Read-models and projections
- Boundaries in complex systems
- Integration inside and outside, using events
- Production readiness - metrics and traces
- Evolving event-sourced systems

Practical examples with use Eventuous, a compact Event Sourcing library for .NET. The session will be most beneficial for .NET developers as most of the building blocks are ready-made. For exercises, participants would need a laptop with .NET installed, preferably .NET 5 or .NET 6.

Awesome Actor Model with Proto.Actor

Many have heard about the Actor Model pattern but not that many use it in production. There're several reasons for that but the most important one is probably the size and complexity of the most popular Actor Model implementations in .NET world - Akka.NET and Microsoft Orleans.

Proto.Actor often gets unnoticed, although it is quite simple, very fast and easy to grasp. It is, of course, open-source and, what's important, there're several implementations of Proto.Actor, including .NET, Python and Go.

After using Proto.Actor in production at scale for more than a year, Alexey is ready to share his experience on building fast, scalable and reliable applications that can process billions of events per month.

OpenTelemetry will save your day (and night)

Microservices and distributed systems became the norm over the last couple of years. With all the benefits of having small, decoupled units of processing messages and requests, comes the pain. The pain of losing control. The pain of not knowing what exactly happened when users start to complain that some part of a large system misbehaves.

We learned about monitoring, metrics and traces - those pillars of observability. We use a bunch of tools to collect and categorise the information, but then we start drowning in the sea of logs, graphs and dashboards.

OpenTelemetry aims to address all aspects of collecting the insights of distributed systems using one API and one protocol. With the release of .NET 6, we got a new way to collect metrics, provided by the standard package. Let's look together how a distributed system built with .NET 5 and 6 can be instrumented to use OpenTelemetry and how can we use all the information it delivers to diagnose complex issues and get alerted properly when things don't go well.

Proper instrumentation and alerting will, for sure, save your day more than once. It will also save your nights and weekends too.

Mind the Gap

With EventSourcing ever-growing popularity, many voices start to express worries about the underlying technical complexity of the pattern. It appears that not only the pattern needs serious considerations before applying, but also requires extensive technical knowledge of its implementation.
These days, it is quite easy to find materials online about motivations for using EventSourcing. But when it comes to practical aspects of the implementation, we can't say the same.
Such a situation often leads to confusion when developers make repeated mistakes and conclude the pattern itself as a failure.
I build event-sourced systems for a living and have a substantial record of successful implementations during the last several years. Some systems I helped implementing are smaller, some are larger, but they share the same characteristics - stability, performance and high level of observability to help to maintain these systems.
In this talk, I'd like to share my experience with you and explain some of the common pitfalls on the way to a production-grade application that uses EventSourcing in its core. I will also provide a set of heuristics that help me make decisions about particular implementation style for different kinds of event-driven service or application.

Eventuous: Event Sourcing with .NET

Alexey created Eventuous with the intention to make Event Sourcing accessible for .NET developers. Eventuous implements numerous building blocks based on years of experience building production-grade event-sourced systems. Although by far not complete, it provides a solid foundation for either people who are already familiar with Event Sourcing or developers who consider using the pattern but are not sure how to start. The session is mainly a live-coding demo of what Eventuous has to offer at its core. You will see a small event-sourced application built from scratch, and get a gist of what other things you can do with the library.