Using Event Modeling without Event Sourcing
From the day i began to understand Event Modeling, i couldn´t wait to try it in a real project. The opportunity for that came earlier than i expected.
My team of developers were all new team members and we got a big challenge right from the start. With a tight and unchangeable deadline. So technically nothing special in Software. But the requirements were far away from being ready for development.
So i suggested Event-Modeling in order to bring us up to speed as fast as possible. Even though i knew that Event Sourcing was not possible, since we all lacked the experience. Also our client loves SQL and when i tried to explain Event Sourcing it seemed to sound like rocket science to him.
But i was pretty sure that, after all i learned from Adam about Event Modeling, it could help us here anyway. The concept of “Information Completeness” should be valid independently of the database technology behind. Since it simply sais that you are able to explain where the information comes from and where it goes to by example.
And i was pretty sure that this would also work for table based storage. And that it would still be one of the fastest ways to transition from the phase of discussing requirements to development. While at the same time developing a good self-confidence in our understanding for the requirements.
In my opinion big surprises late in a software project, especially concerning the data model, should be eliminated at all cost. They are not only one of the biggest risk. They also tend to kill all the happiness a developer could have while development. Since it may force him to rewrite large parts of the software and also further tightens the time for implementation. Without Event Modeling the customer might not even see and understand how much work these changes can cause.
How?
At first we modeled as if we would use Event Sourcing. So we modeled events. We were aware of the fact, that later we would persist the information in tables. We did that just in order to show the flow of information, regardless of the table based schema. That helped in the first process of understanding the requirements.
And it confirmed my assumption: It works astoundingly effortless and elegant to start from zero and come to the first results. Defining the first cornerstones is a process of good listening to the client, asking questions and directly modeling that to the Event Model.
We began by modeling the beginning part of the story and also the end. The middle part of the story was then filled up more and more. After an Event Modeling session i always had the superb feeling of having learned an awful lot. The Event Model seems to magically lead the discussion to the right questions. You can´t get lost due to the fact that it is always one strand of a story. This way we saved a lot of time by not talking about irrelevant stuff.
Insight 1: We should be exact in our table design
After understanding the requirements better, we developers needed to design our tables. Unfortunately we could not simply keep the events. So we began to design that tables and the changes that are being made to them in write operations directly on the Event Model. Since we had write operations that made several changes to multiple tables, we grouped them within a border.
This way we got to a high level of detail and described all the changes to the fields in our database. The big advantage was that we as developers found good consensus about the details in the data model. And we were able to show that to our client. Dou you remember? He loves SQL. That allowed us to get valuable feedback from him instantly. That happens rarely in projects, because i think the attitude is mainly that the design of tables is “part of the developer”.
With this approach we gained confidence in our understanding and were able to show our level of understanding at any time. For open questions we were always able to jump right into complexity on our Event Model.
To discuss that many requirements in such a short amount of time was more intense than i was used to. But as i expected, it got us into development quite rapidly. We were also able to parallelise the development at a very early phase by using the technique Adam calls “slicing”. That way everybody knew exactly what the other developer was doing without needing to know how exactly he would do it.
The cool thing is: Development becomes a lot of fun this way. Why? Because it minimizes the potential for conflicts. Most things that could lead to a different point of view later, might have been clarified already in the Model.
Insight 2: Write operations always have a meaning to business
When i modeled the write operations to tables on to our Event Model, i felt quite clever doing that. But as the complexity grew, i quickly noticed that it made our Model harder to understand. And it was mostly due to the missing names of events that would normally exist in an Event Model.
It makes it hard to navigate within the model after re-opening it after some time. I started to doubt that Event Modeling is still the right tool for us.
What i didn´t understand before: Every event in Event Sourcing is semantically relevant, even though it carries no further information with it. Table-based storage is missing this piece of information. And that became painfully obvious to me at that moment. You´re not only losing information later in the working application, but also in the model that helped to understand it.
So i changed my approach. Every write operation to our database has to be somehow relevant for the business. And therefor it must be made transparent and understandable for business people. And since not everybody is able to understand and discuss normalised data, i started to give each of our write operations a name. Like i would do with events. Even though later that information would be lost, we still could use it in the model for better expressiveness.
I am quite happy with this approach and think we found a sweet spot for using Event Modeling without Event Sourcing this way.
