The art of simplicity

In one of our applications, we had the following code: We were using events to share information between different modules in our Modulith. These same events were also stored in an Event Log as a source for possible projections into a read model. However in case of the code above, the ‘operationId’ for was always {00000000-0000-0000-0000-000000000000} when deserializing the ProductCreated event. Do you notice what is wrong? Important to notice here is that our ‘OperationId’ is a readonly property that is set through the constructor. You may already wonder why the JSON serializer is smart enough to fill in this property if only a getter exists. This is because it has a neat trick where it looks at the constructor of the object and if it can find a corresponding parameter, it will call the constructor and pass on the parameter value. Now that you know this, take a second look at the code above. The reason it fails is because there is a typo in the constructor of the ProductCre...

If you want to organize your own Event Storming workshop, here is a good cheat sheet to get started with: https://github.com/wwerner/event-storming-cheatsheet This cheat sheet aims to provide a short opinionated summary of preparing and facilitating an Event Storming Workshop. It is not intended to give a complete introduction to the topic, prior knowledge on DDD and Event Storming is required to make responsible use of this document.

If you are new to EventSourcing I can recommend the eBay Tech Talk in Berlin, Raimo Radczewski did a great introduction about EventSourcing and CQRS. Best quote during the talk: One table with three columns; with EventSourcing, that’s all you need to develop an e-commerce system, a CRM app, or any kind of application you can imagine.