Oskar Dudycz
Event Sourcerer
Wrocław, Poland
I'm a developer, technical team leader, and architect. I started a career before StackOverflow existed. For over 16 years, I've been creating systems close to the business process. I believe that Event-Driven Architecture and Event Sourcing are great ways to achieve that.
I'm an active open-source developer and one of the Marten library maintainers. I'm sharing my journey and findings on my blog https://event-driven.io and practical samples at https://github.com/oskardudycz.
Links
Awards
Area of Expertise
Topics
Event Sourcing in production
Event Sourcing is a pattern that is quickly gaining popularity. Many companies see the advantages it brings, e.g. business focus and keeping all information about the business process. It can also be a great input to analytics, providing increased diagnostics and tracing. Nowadays, that's essential for running a system on the scale.
There are already decent materials teaching how to start the journey with Event Sourcing, yet it's not easy to get certainty that what we designed will work on production. Even when we get there, it's worth revisiting lessons learned and discovering what we can improve in preparing for the upcoming challenges.
The goal of this workshop is to strengthen all of the critical aspects of running event-sourced on production:
- modelling (like keeping streams short, managing consistency and efficiently handling business logic, best practices and anti-patterns),
- managing schema evolution, so events versioning,
- advanced projections design and resiliency, so how to get the best from events to efficiently get read models and insights from them,
- DevOps techniques (like traceability, blue-green projection rebuilt, archiving old data),
- handling distributed processes and integrating with other systems,
- putting event sourcing as a vital part of the whole architecture (so how to integrate it with non-event-sourced modules, defining private and public schema).
After the workshop, you'll understand and practice techniques that will allow you to run your Event-Sourcing system on production.
All the exercises will be backed by the versatile knowledge of the trainer, Oskar Dudycz. He'll share his experience building systems like Marten and EventStoreDB and working as an architect and consultant in many Event Sourcing projects.
We'll start with the project of the system that looks fine as the first production deployment. Through group exercises, a mixture of modelling and practical coding exercises, we'll analyse potential issues step by step. We'll learn how to refactor it step by step without breaking it. That will allow us to fix the boundaries, consistency guarantees, and resiliency. We'll practice both adding new capabilities and changing existing ones. We'll practice schema evolution and DevOps practices like projection rebuilds. We'll end with a more robust and prepared-for-the-next-challenges system.
CQRS is simpler than you think with C#11 and .NET 7!
CQRS is quite often perceived as an over complex pattern with a lot of redundancy and ceremony. Too often it's explained pushing towards multiple databases, eventual consistency, DDD, and Event Sourcing. In this webinar, Oskar will show that it's the opposite in reality.
During live coding, Oskar will show how CQRS can help in tackling the layered architecture complexity. He'll build a simple but real WebAPI. Then he'll spice all of that with all the goodies from C#11 and .NET 7 to help achieve that. Records, Nullable Reference Types, Endpoints etc. The main focus will be on CQRS and pure .NET, not Event Sourcing, or DDD.
Removability over Maintainability
We’re making the most significant decisions when we’re dumbest. We don’t know our domain, and we don’t know the tech stack, yet we’re trying to guess the best option and present it as wise architecture decisions. Why is that?
I think that we're optimising for the wrong factors. Maintainance is an important aspect of our systems, but should we optimise for it? What if our system won't ever need maintenance, or maybe just a portion? How do we know what parts will survive?
We'll discuss that during the talk and learn how to be frank with ourselves. How to embrace risk and chaos, knowing that our systems might not end up as we initially were guessing. How to accept that leftovers may be stronger than complex but fragile design.
Event modeling anti-patterns
Have you heard about Passive Aggressive Events or CRUD sourcing? Or maybe about the Clickbait event?
If you don't, you better check this talk, as knowing only best practices is one side of the coin. Knowing what NOT to do can be even more important.
During the session, you'll learn the specifics of event modelling, starting with worse practices and knowing why and how to avoid them.
You'll also find out that there's a thin line between bad and good practices: context.
Slim your aggregates with an Event-Driven approach
Aggregate is a useful pattern, but it's tricky to get it right, especially when starting. The initial focus on business logic is too often replaced with state obsession.
During the session, I'll show you how an Event-driven approach and a bit of functional composition can help to slim them down.
All of that will be as live refactoring that starts from a typical, bloated implementation and ends with code focused on behaviour and simplicity.
PostgreSQL Superpowers in Practice
Intriguingly, PostgreSQL is both popular and underrated. Many people use it because it's for free, not knowing its superpowers. Postgres has become a model example of how to create relational databases. In many elements, a model engine. We will look at its unusual features, such as partitioning, push notifications, rich extensions ecosystem etc. We will avoid boring scenarios, play with the code and see what it can be useful for in practice. We'll end up with a simple but real fleet management reporting and alerting scenario.
From CQRS to CRUD in Practice
CQRS is usually shown as the pattern that adds too much overhead. People wrongly assume that it can be used only in enterprise projects. In a nutshell, CQRS is a structural pattern that shows how to structure your architecture.
I show how to start with the classical layered CRUD monolith and, step by step, go to the CQRS, explaining that you don’t need multiple databases, event sourcing and fancy tech stack. What you need is the focus on the business and slice your architecture vertically to get more explicit and straightforward code.
Facts and Myths about CQRS
CQRS is usually shown as the pattern that adds too much overhead. People wrongly assume that it can be used only in enterprise projects. In a nutshell, CQRS is a structural pattern that shows how to structure your architecture. You need to slice it by the behaviour: business logic and queries. I'll explain where those myths about multiple databases, eventual consistency and event sourcing come from. I'll show CQRS as it is, so simple pattern that allows on-point optimisation and easier evolution.
Let's build event store in one hour!
During the session, I'll show how to build your own event store with a Relational database as the storage. What's more, I'll do it in only 1h!
While building, you'll learn and understand all the intrinsic details of how Event Sourcing works, so:
- storing events,
- getting back the state,
- read models (snapshot, projections).
- etc.
All of that, in the end, will be connected to a real-world app with DDD and CQRS.
Event-driven revolution, from CRUD to Event Sourcing in practice
Monoliths are fine, but Event Sourcing gives us more options. We do not lose any business information. It facilitates the understanding of the business process and modules autonomy. During the presentation, we will start with a classical NodeJS application written in TypeScript. We will transform it into an application using Event Sourcing. We will also find out if it is really worth it.
How to deal with privacy and GDPR in Event-Sourced systems
Privacy is an essential topic in software systems nowadays. The recent regulations with international repercussions, such as GDPR forced the industry to consider it even if they had not before. It's a fair move, but applying those rules may be non-trivial. In the webinar, I will explain the most popular strategies for dealing with privacy in event-sourced systems.
Keep your streams short! Or how to model event-sourced systems efficiently
In event-sourced systems, no data is lost. We record new facts after each business operation. That's a huge benefit but also a challenge. At some point, we realise that we have too many events in our streams. That causes a whole variety of issues: operational, performance, versioning, but also cognitive load and blurring the entire picture. In this talk, you'll learn how to deal with the temporal aspect of our system and why it's essential to keep your streams short. You'll learn strategies and techniques to model your domain into streams efficiently. Thanks to that, you'll learn to efficiently create and maintain your event-sourced system, avoiding common pitfalls.
Pragmatic Event Sourcing in .NET with Marten
Event Sourcing is like the Nessie, all heard about it but not much have seen it. The presentation will show how the moderns systems can benefit from that pattern with the practical examples using Marten (https://martendb.io/documentation/events/).
Marten is an interesting framework that benefits from the great JSON support in Postgres. It makes it an Event Store (and DocumentDB) keeping benefits of the Event-Driven systems and allowing them to keep strong data consistency.
All of that will be flavoured with a dose of CQRS and DDD.
The Light and The Dark Side of the Event-Driven Design
Recently Event-Driven Design became one of the most popular Buzz Words. This approach is shown as the model way of the modern, scalable systems. I'll play the devil's advocate and show in practice what may go wrong. I'll show that this experience may be painful. I'll tell of how you may end up with distributed monolith and the concrete tips on how to prevent that. I'll explain all those enigmatic terms as idempotency, eventual consistency, at least once delivery, etc. I'll bust few myths and show facts without evangelisation. All of that will be flavoured with a dose of the healthy pragmatism.
Let's build the worst Event Sourcing system!
Everyone likes to talk about best practices. We'll go the other way round and gather all the worst practices to learn how to build the worst Event Sourcing system!
Event Sourcing is perceived as a complex pattern that’s challenging to learn. In fact, it's pretty simple, but the way it's taught may lead to such a conclusion. By going through the worst ideas, we'll also learn the essence of Event Sourcing.
Workshop: Practical Introduction to Event Sourcing
Event Sourcing allows you to create business-related applications. Recording events (facts) about the business process gives a complete understanding of your workflow and reflects them in the code. It is wrongly considered a complicated pattern that is challenging to apply in practice.
## Learning objectives:
The workshop will be hands-on and teach you how to use Event Sourcing, giving you solid foundations. You will understand after them:
* when and how to use it and what benefits it brings,
* how to reflect your business logic in the code using events,
* differences to the classical approach,
* different tools such as Marten and EventStoreDB and the differences between them,
* how to use Event Sourcing on your system,
* challenges related to Event Sourcing and recommended solutions.
## Summary:
1. Introduction to Event Sourcing. Basic terminology (event, stream of events, command), differences from the classical approach.
2. What is Event Sourcing, and how is it different from Event Streaming. Advantages and disadvantages.
3. Write model and data consistency guarantees.
4. Various ways of handling business logic: Aggregates, Command Handlers, functional approach.
5. Projections and best practices for building a read model on the.
6. Challenges in Event Sourcing and EDA: delivery guarantees, event processing order, idempotency, etc.
8. Saga, Choreography, Process Manager, handling distributed processes.
7. Event Sourcing in the context of application architecture, integration with other approaches.
8. Good and bad practices in modelling and handling events.
9. Event Sourcing on production, evolution, event versioning, etc.
## Requirements:
* understanding of the basic building blocks of the application design,
* experience in one of the languages and platforms: C#, Java, TypeScript (code exercises will be done using them),
* positive and open-minded attitude ;) .
NDC London 2024 Sessionize Event
Build Stuff 2023 Lithuania Sessionize Event
Domain-Driven Design Europe 2023 Sessionize Event
NDC Oslo 2023 Sessionize Event
Techorama 2023 Belgium Sessionize Event
Swetugg Stockholm 2023 Sessionize Event
NDC Oslo 2022 Sessionize Event
Domain-Driven Design Europe 2022 Sessionize Event
EventSourcing Live 2021 Sessionize Event
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top