πΏ Model - what is it?
A model is not a copy of the real world, but a representation made for a specific purpose: to solve a particular problem and answer specific questions. As programmers, we constantly create abstractions in order to understand and implement project domain and requirements.
However, you use various models (or abstractions) every day, perhaps without even realizing it. When you drive a car, the lines forming the road on the navigation system are not the actual street you are driving on, but they answer the question: "How do I get to my destination as quickly as possible."
πͺ It depends on the point of view
So, what makes a "good model"? It depends on who is asking. When I ordered a custom kitchen, I received two models: one technical drawing (on the left) and another in 3D (on the right). If I want to see how the colors match and imagine if the arrangement of the appliances will be ergonomic β the 3D model is suitable. However, for the person who has to cut and assemble the furniture, it will be useless because it does not provide the exact measurements. This is an example of two different representations of the same reality β both useful, but in different contexts.
π‘οΈ Heroes III β Who attacks first?
Do we already know what a "good model" is?
We can still repeat the standard consultant's answer like a mantra: "it depends."
But it's important to know β what does it depend on? It depends on what the question is.
You don't have to look far for an accurate example, as the following screenshot from Heroes III provides it,
where we can see two representations of the same "reality": the battle between armies of creatures.
Of course, the word "reality" is not entirely appropriate in the context of a game, but Domain-Driven Design methods can be applied here as well.
Nowadays, it is natural β various businesses (e.g., job listing portals, online stores, banks, etc.) are so closely tied to software
that it would be misleading to say that as programmers, we only model something "real" that exists outside of computers.
The presented screen shows two different models of the same battle situation, but answering different questions.
β¬’ Model #1: Battlefield
Composed of hexagons (similar to squares in chess) on which creatures move.
A glance at this model can answer questions such as:
- What is the Angel's movement range? The currently dimmed hexagons indicate where the highlighted Angel can fly or attack a creature standing on them β in this case, only the Dragon.
- How many creatures has the player lost? In the bottom-right corner, you can see that one group of Angels has already fallen.
- Where is the best spot to attack with the Dragon (as it can attack 2 adjacent creatures)?
βΉ Model #2: Battle Queue
Visible at the bottom, depicting the upcoming moves of creatures and the battle rounds.
Here we have a very specialized model, serving practically to answer one question:
- In what order will the creatures move?
Thanks to this representation, we have a clear answer, which we could extract from the previous model, but with much more effort.
It would require us to analyze the stats of each creature (their speed), which still wouldn't be enough because factors like artifacts owned by the hero or cast spells also influence the move order.
Additionally, a creature can wait each turn, placing it at the end of that round β without a visible queue, each player would have to remember this.
The model is much simpler compared to the battlefield and contains less information (e.g., we don't need to know the creatures' attack strength because it doesn't affect the move order), but it better serves its purpose.
In Event Sourcing terminology, one could say that the Battle Queue model is a projection of events such as CreatureMoved, CreatureAttacked, CreatureWaited, SpellCasted, etc.
π€ Experience -> Automation
In the original version of the game, only the battlefield view was available (without the initiative bar). However, subsequent expansions/mods added this feature based on player experiences. This is an example of automating a process that was previously done in the players' heads, taking away a lot of time and enjoyment from the game.
Maybe in your company, there are Excel sheets that waste a lot of time and money until someone (like you) automates them?
If you have the opportunity, it's worth spending a day outside the IT department to listen in on what people complain about whose work you're supposed to simplify with your software.
You might find HotSpots faster than by sticking notes during EventStorming!
π³οΈ Have we found the Holy Grail?
Is it possible to illustrate all contexts with a single model? This is often what tutorials or documentation for a given framework show you (it's impossible to summarize all the books on best practices in such a place). Unfortunately, even developers with many years of experience still try to do this in applications with complex business processes. And it works, until you eventually start getting lost in the jungle of if-statements. They then excuse themselves with a misunderstood "pragmatism" and say, "we'll fix it later" β but you know that "later" never comes.
That's why you should invest time now to expand your toolkit and choose the right solutions for the specific class of a problem. And be sure to apply them in practice β only then you will grasp their full potential!
The methods I will present are not a Holy Grail that save every project for sure. However, the most important thing is to be aware of alternative approaches to those you usually use and to be able to choose the right one in a given context in order to solve a specific problem using the most appropriate available tool.
If you don't know that a power drill exists, you'll screw everything in with a screwdriver until someone tells you about its existence.
ποΈ Categorizing models
In your dresser in the bedroom, the most important thing is to know what you will find in each drawer. Once you know that, you can apply the appropriate strategy for each one: you neatly fold your trousers, but you likely toss your socks in loosely.
Anyone (or the programmers who came to maintain that software later) who has ever tried to create one huge model consisting of hundreds of tables (or a dresser with one giant drawer) that is supposed to be "one-size-fits-all" has sooner or later failed. Let's focus on dividing into logical business subdomains rather than technical layers or microservices. This way, each of these problems can be solved in a simpler (and probably cheaper) manner, and developers can avoid cognitive overload.
A model can't exist without boundaries (just like drawers set boundaries in a dresser), because then it would just reflect the real world. All models are wrong, but some are useful in a specific context (like the mentioned kitchen designs). To find the right model for certain context, we need to look at the problem from different perspectives.
If you want to actively participate in modeling the solution or just don't miss the upcoming parts, let's sign up for my mailing list HERE.
Top comments (0)