Tue-Wed, Sept 17-18
In this workshop you will learn that with little effort you can improve your workflow by building your own set of tools made specifically for your context.
Scaling applications, refactoring models, testing the solution, debugging problems, proving what happened, or deploying to production; CQRS and event sourcing make it easier. But all these advantages come at a cost:
- Compared to traditional applications there is often more ceremonial code involved before you have your first domain model hooked up to your application.
- When you move to an event sourced model you lose the default view on the current state of the system.
- There is no easy way to correct little mistakes by simply adjusting a value in the datastore
- Asynchronous handling of messages increases complexity when it comes to debugging and monitoring.
- Although evolving models in CQRS can be easier, it still requires you to understand how the current version of the model works. It can be a challenge to communicate about this in an effective and efficient way, especially in large teams.
- While commands and events can help software testers and product owners pinpoint what has happened and why, it can be challenging to see the forest for the trees if all you have is a list of millions of messages.
Unfortunately there are not a lot of tools that help us overcome these typical challenges of event sourcing and CQRS. Traditional CRUD based MVC applications benefit from decades of free and paid-for tooling that help you get the job done faster. In the CQRS and event sourcing world that is not the case. While there are frameworks and libraries available, they generally constrain our models and our way of building software. They do so without providing a comprehensive set of tools for addressing the problems mentioned before.
The cry for a lack of tooling for CQRS and event sourcing is as old as the approaches are themselves. So where does that leave us? What can we do?
- Seeing an overview of all the events of a specific aggregate in your web application by opening up the developer tools of your internet browser.
- An enriched view of the events in your event store that allows you to navigate to associated streams.
- Having links from your events to the commands that caused them in the view of your event store.
- A testing framework that can be understood by domain experts because it works based on domain events and commands.
- Downloading an integration test for your testing framework after reproducing a problem in a production environment.
- Your test scenarios visualized identical to your event storming workshop.
- A conceptual framework that makes it easy to add support operations and forms for correcting mistakes to any list.
- Visualizing trends using your existing analytics toolset.
- This and more, applied in such a way that it becomes an integral part of your day to day workflow
[I] liked the approach...liked the constant retrospective, the content learned and the whole interactivity.
Investments in tooling pay off quickly. Especially when you take small steps. Together we will look at different tools that can help us with building, testing, debugging and changing your software.
With examples taken from real projects you will experience that specific tools can make you more efficient and how they would fit in your workflow. Following each example we will implement the tool in the language of your choice. If you bring your own event sourced domain models we will do so given the constraints of your specific context.
The goal of the workshop is to inspire you to build tools that fit your context and to show you that it can be done with little effort. After attending it you will be enabled to build tools yourself in the future.
- Thorough knowledge of CQRS and event sourcing.
- A laptop with a “Hello world” application in a language that you’re proficient in.
- Setup of a testing framework that can run integration tests against your “Hello world” app.
- Optionally you can bring your own event sourced applications.