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.
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.
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.
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.
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.
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.
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.
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).
All of that, in the end, will be connected to a real-world app with DDD and CQRS.
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.
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.
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.
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.
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.
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.
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.
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.
* 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 ;) .