Alexey Zimarev

Information & Communications Technology

Domain Driven Design Event Storming eventsourcing .net

Larvik, Vestfold og Telemark, Norway

Alexey Zimarev

Reliable messenger

Alexey is CEO of Ubiquitous AS, Developer advocate for Event Store, Chief Architect in ABAX and the author of “Hands-on Domain-Driven Design with .NET Core” book.

His particular interests are in event-driven architectures, domain-driven design, distributed systems, and event-sourcing. Alexey contributes to open-source software as a member of MassTransit and Proto.Actor projects, and a maintainer of RestSharp. He manages the Domain-Driven Design Norway meetup group and speaks at technical conferences.

Follow Alexey on Twitter at @Zimareff.

Current sessions

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 and the author of "Hands-On Domain-Driven Design with .NET Core" book for a full-day workshop for developers and architects who are willing to learn practical aspects of implementing Event Sourcing in production systems.

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 them 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
- Production readiness - metrics and traces
- Evolving event-sourced systems

Alexey will write code in C# but participants can use any language. EventStore will be used to persist events, you might get better prepared if you check if there's a client library available for your language. The official client is available for .NET and community-driven libraries exist for Java, NodeJS, Python and other languages.


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 a 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, potentially, one protocol. Let's look together how a distributed system built with .NET Core 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.