Cover photo source: Heroes of Might and Magic III, Ubisoft
🧠💪 In this series we will:
Discover how modularization influences business development and opens up opportunities for new products.
Translate sticky notes from EventStorming and Event Modeling directly into working code.
Explore daily and rapid enhancement of your business process modeling skills.
Improve project quality using methods better than code review.
Consider diverse stakeholder perspectives such as UX/UI, frontend, backend, and analytics when modeling processes by mean of Event Modeling.
Generate unit tests from the appropriate model notation with the help of ChatGPT.
Keep code complexity aligned with the business process being modeled.
Implement the Decider pattern to express business logic in a functional style.
Familiarize yourself with various modeling practices that will inspire your further growth.
Revolutionize your programming experience forever.
Could I describe all of this using examples like a cinema or a shopping cart? Sure! But why keep repeat examples on the same domain again and again (others done it well in books and during conferences)…? It’s time to enter the world of heroes, magic, elves, and other fantastic creatures.
Event Modeling allows us to tell a story like frames in the movie and connect on a single diagram different layers of the system: user actions, interface designs, REST APIs, data storage, etc.
This ensures that there are no gaps in the requirements and everyone involved in the project are on the same page.
Illustrated dependencies show where work can proceed in parallel.
The result is a project that we translate directly into code, eliminating misunderstanding and time-consuming discussions during code reviews.
Above, you can see a piece of Event Modeling of the autonomous recruitment model in Heroes III. But how did we get to this point!? And what does “model” mean, especially “autonomous”!? After all, no one recruits Angels at the very beginning of the game… Similarly, no one knows right away what a given business process looks like and what abstractions to use to express it.
Exhausted Hero! It’s time to leave the tavern and dive into the world of might (proven patterns and heuristics) and magic (also known as intuition) of modeling in the spirit of Domain-Driven Design. 🧙♂️
Recently, after a few years’ break, I launched Heroes III and immediately began to analyze how I would program something similar, based on my experience from commercial projects (disclaimer: I don’t develop games, but I automate business processes such as publishing job advertisements, working in a call center, and in a bank, etc.).
Flashbacks from my first commercial projects and the mistakes I made also returned, as I used to start implementation without the proper process of learning and planning. Although it is just a game (but the best I’ve ever played!), you can find many analogies to real business processes in it, which I will explore together with you (starting with this post) and translate into code.
👁 The curse of knowledge
A hero’s stats affect their troops (creatures) in combat, and the combat results affects the hero’s army (because of lost creatures).
You can hire a hero in the tavern, which can be built in the town. You recruit the creatures in unit dwellings, which may or may not be in the town. The tavern works the same way. Creatures availability renews every week, unless the astrologers proclaimed a week of plague. Of course, you also need resources to buy them, which are collected on the map… Oh, and don’t forget to develop your hero!
This is just a snippet of the requirements you would get if you asked a “domain expert” about the processes in the world of Heroes III.
Imagine how confused my wife was when I wanted her to play with me for the first time and I tried to explain such complicated game rules as an “expert”. She gave up after a while… And that was just the beginning. It’s very similar when the so-called business tries to explain its project requirements to us…
That’s why our task (and responsible duty as a Software Engineer) is to carry out the process of knowledge crunching, which means extracting domain knowledge from those who have it. We need to learn to ask the right questions at the right time to avoid being overwhelmed by the experts’ knowledge. Fortunately, there are proven methods for this, developed by the Domain-Driven Design community. I will use some of them, and you can find more on GitHub DDD Crew. This post is the first in a series. In the following posts, we will level up in the Mage Guild and dive deeper into the mentioned techniques.
♞ Why Heroes III?
I want to show you my current state of knowledge, how I execute projects, and my way of thinking, as well as my engineering practices workshop. I will dive into the specifics of the methods used in separate posts.
For educational purposes, even though the domain is literally fantastical, it is much closer to real-world projects than the examples you often see at many conferences, such as “cinema” or the repeating again and again “ecommerce” example, seen in many books about DDD and Event Sourcing. Every cinema and shopping cart operates differently, so when we invent business requirements, we shape not only the model but also the reality. Here, the reality is already defined by the rules of the game, and we must discover and properly model it—just like in a real project.
Although, of course, many great books and presentations by extremely competent people have been created based on the mentioned standard examples, from which I also learned a lot. It’s worth checking out examples by Oskar Dudycz (a leading expert on Event Sourcing), where he models a shopping cart in many different ways: .NET, NodeJS, Java.
🏋️ Training the intuition
I invite you to join this campaign, where we will model the world of Heroes III together, based on practices such as DDD and Event Modeling. Does such “fun” really make sense?
Often in the modeling process, an unexpected flash of intuition appears, and someone nearby may feel like you’re pulling a rabbit out of a hat. This still-unexplained puzzle of intuition is most likely unconscious knowledge derived from experience. We must openly admit that intuition favors those who have had the chance to be exposed to various cases. So, the more cases you see, the better you model. ~ Jakub Pilimon & Sławomir Sobótka (DomainDrivers.pl)
I want to build an intuition with you so that when you encounter an analogous case in a real project, your brain immediately knows how to react. If you want to actively participate and don’t miss the upcoming parts, let’s sign up for my mailing list HERE.
