Are you looking for an entry point to Event Sourcing and CQRS? In this workshop, Roman Sachse takes a DIY approach to Event Sourcing — offering you a unique chance to learn to build a FullStack Event Sourced application that spans the backend and the frontend.
Domain Driven Design is a way of thinking about the needs of the customers first and putting an emphasis on their language and interactions. A semantic domain model that is shared between business stakeholders and developers benefits everyone. Tightly connected to DDD are architectural patterns like Event Sourcing and CQRS because they allow domain models to be expressive, understandable, and scalable at the same time.
The problem is that they are quite different from traditional ways of writing software and it is not always perfectly clear where to start. Everything sounds quite complicated and there are many new concepts to learn. Do you need to use one of the available frameworks? Do you really need solutions for problems that you might never encounter?
In this workshop, I want to take you on a journey that will enable you to build your own CQRS and Event-Sourced system. Together we will define the requirements, and I am going to provide you with ideas and approaches to fulfill those requirements. We will be discussing and tackling the problems that arise in these systems first-hand and tailor the solutions to our applications specific needs.
Event Sourcing, CQRS and their benefits are mostly applied to the backend of applications, but a semantic domain model also benefits the UI. Unfortunately, these semantics are often lost in translation when transferred to the frontend. In the second part of this workshop I will show you a functional approach that allows you to actually reuse your domain types, your read-models and even your domain logic from the backend on the frontend. This is possible by combining CQRS/Event-Sourcing with an expressive frontend using the MVU pattern by applying an overall messaging architecture. With the help of this architecture it becomes possible to build eventually connected systems or even "What-If" scenarios on the frontend with ease.
The language in use will be F# because its pragmatic functional first architecture is are a perfect fit for these kinds of architectures, but the concepts should transfer to other languages easily. In case you have never worked with F# we will start the workshop with an introduction to the language that will cover all the concepts you need to follow along. The workshop will introduce all the theoretical concepts you need but it puts a strong emphasis on practical exercises. These will be done either in small teams or with the whole group as a mob programming experience.
Learn how to:
Understand the basic usage of F# and follow the rest of the workshop
Understand the most important concepts and challenges in Event Sourcing and CQRS and be able to start implementing an Event Sourced application independently
Learn and understand how to build a frontend that integrates nicely into an Event Sourced application
- Introduction to F# syntax and uses
- Functional thinking
- Getting rid of null with Options and Result
- Algebraic Data Types
Event Sourcing / CQRS - Do it yourself
- Putting the Behavior first (Build behavior / Domain Model)
- Testing Event Sourced applications with BDD-style tests
- Building an Event Store (in memory and persistent)
- Building Event Listeners, Command Handlers and Query Handlers
- Understanding and building Projections
- Build read-models (in-memory and persistent)
- Creating a CQN Port
Domain Driven UI
- Introduction to the Elm-Architecture/MVU with Fable.Elmish
- Asynchronous Operations and Commands
- Modelling the state of the application
- Using Read-models of the backend as the source of truth for MVU applications
- Making use of available libraries like Fable.Remoting
- Implementing What-If scenarios
The workshop is intended for software developers that want to learn how to create Event Sourced applications. Experience in any functional programming language is helpful but not necessary.