Alexey Zimarev

Information & Communications Technology

Domain Driven Design Event Storming eventsourcing .net

Larvik, Norway

Alexey Zimarev

Reliable messenger

Alexey is CEO of Ubiquitous AS 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.