Eventmodeling - Describing business rules with "Given / When / Then"
Martin Dilger
Educating event-driven developers, Building event-sourced Software-Teams | Eventsourcing mit Axon, Spring Boot und Java / Kotlin | Autor "Understanding Eventsourcing" | [email protected]
--
In the last episode of the "Eventmodeling & Eventsourcing" - Podcast we mainly discussed "Given / When / Then" scenarios to describe business policies and touched on "slice-based architectures" especially how they simplify concurrent development and version control.
If you did not have the chance to listen to it, here is the link to the episode on youtube.
As always, we will pick one topic from the podcast and go into a little bit more detail in this newsletter. This time - let′s talk about the different types of "Given / When / Then".
Why different types you might ask?
We have business rules, when we change the system, we have business rules when we query the system and we have business rules for background tasks.
Rules to change the system
To change the system, we use "state change"-slices, which typically consist of a screen, a command (in blue) and a resulting event(s) (in orange).
The customer can order something from the "orders page", by clicking a button to "submit the order", which results in the order being stored in the system.
Typically we have to deal with numerous rules to change our system. The guardrails to keep the system valid.
We describe these rules using "Given / When / Then".
With "Given" - we set the system into a certain state. "When" describes the action that is executed on the system in this state. "Then" describes the expected outcome - the new state of the system.
This results in visual and very easy to understand business rule descriptions, which can even be translated into executable test cases. Maybe you know "Gherkin"-Syntax to describe behavior. "Given / When / Then" is basically the same, just more visual.
Example:
"Given" no previous events ( I then omit "Given" ), "When" the "Submit Order"-command is executed, we expect the "Order Submitted" -event to be stored using the same order id.
There might be another rule which prevents us from submitting the order twice.
"Given" the order was already submitted, "When" we try to submit it again, we expect the system to be in an error state.
What about Read Models and Automations?
In the podcast we briefly discussed how Adam and I handle automations, and we do this slightly differently.
I provide "Given / Whens" for Automations accompanied with "Given / When / Thens" if applicable.
Adam treats automations exactly like state change slices, basically regarding the automations as automated humans.
Assume we have an automated task for notifiying the customer (maybe doing an API call to AWS SNS)
I would start with a "Given / Then" description.
领英推荐
This specification is typically translated into an running test (as also described in the book ).
So I set the system in the state, that an order was just submitted ( by assuming the "Order submitted"-Event in "Given" ) and I expect the "customer notified"-Event to be issued automatically ( omitting the explicit "When" )
Adam would treat this as whole functionality as a "Given / When / Then" like this, ignoring the fact it′s an automation. I might add the "Given / When / Then" if it helps understanding.
If you want to see how I do this in Miro using the "Accelerate Tools" - here is a quick link to the video (it′s only a few seconds long ). It shows how the integrated Scenario-Editor works and even how the test-cases can be created automatically by the system.
You find another short video describing how to model this in Miro here.
"Given / When / Thens" are such an important topic and often ignored in the beginning. That is a mistake. You should use them from the start to descibe how your system works.
If you have questions about this, join us in the Community Discord. You′ll always find someone to answer questions there.
Let me know what you think of this newsletter. Since we are just starting with this, any feedback is welcome.
Just answer to this e-mail with one sentence and one thing, we could improve. Thanks!
What else happened?
My book "Understanding Eventsourcing" is still #1 on Leanpub. I′m so proud of that.
Changes in the next version of the Miro Plugin - Linked Given / Thens
We found a nice workflow to integrate Figma & Miro for Eventmodeling. Find out more here
If you buy the book, you′ll get all "missing chapters" automatically.
And of course - follow us in the weekly podcast:
See you next week!
Want to practice your skills in a safe environment?
The Online Course "Implementing Eventsourcing" gives you exactly that. It′s a perfect companion to the Book "Understanding Eventsourcing"!
Everything I know about Event Modeling & Event Sourcing in one course.
Software Developer, Solution Architect, BPM Crafter, Speaker, Entrepreneur
2 个月Hi Martin, I believe that the specification by example is the most important step in Event Modeling. It is the main difference to other collaborative modeling techniques like Domain Story Telling and allows a transition from analysis to design. And depending on the focus of the When part - you can design command handlers, query handlers, automation or any other part of your system…
Senior Software Developer bij Nedap Livestock Management
3 个月Hi Martin, nice to have a small recap on the podcast. Helps to clarify some things. I have a question about the example you give here. If I understand correctly, we should only model “state-changing events”. Is CustomerNotified a state-changing event? Or is sending out an email just a side effect of the OrderSubmitted event? Sending this notification seems part of the business process, so in that regard it should be in the model. But should it also be stored in the event store? What are your thoughts on this?
Freelance Lead Full-Stack Developer | Helping Enterprises Accelerate Delivery with Fast, Strategic Solutions
3 个月There might be another rule which prevents us from submitting the order twice – das erinnert mich an ?hnliche Situationen aus der Praxis. Ich finde den Ansatz gro?artig und bin generell ein Fan von Methoden, die dem Breadboarding ?hneln und dabei die technischen Details zun?chst in den Hintergrund rücken. Solche visuellen Darstellungen halte ich auch bei PR-Reviews für ?u?erst hilfreich. So l?sst sich der gesamte Prozess, von der Anforderungserstellung/Softwaredesign bis hin zur Implementierung, nochmals zu validieren.