“All models are wrong, but some are useful.”
Building an effective model to represent a business entity in the code is the brick of building an effective solution for a business problem. This blog post series aims to highlight and discuss the various best practices to build effective models. Before we do that, let’s first understand what the Model is, what it means to be Effective, and how to work with Bonini’s Paradox.
“A model is a simplified representation of a thing or phenomenon that intentionally emphasizes certain aspects while ignoring others. Abstraction with a specific use in mind”
What is a Model?
A model is not a copy of the real world; it is a construct that helps us make sense of real-world systems. In its essence, a model is an abstraction. Let’s take a canonical example of a model — Map.
Any map is the Model of the planet, including navigation maps, terrain maps, world maps, metro maps, and others. But, none of these maps represents all the details of our planet. The map is not a copy of the planet details in depth. Instead, each map contains just enough data to support its particular purpose: the problem it is supposed to solve.
“A map is not the territory it represents, but, if correct, it has a similar structure to the territory, which accounts for its usefulness.”
Bonini’s Paradox
How do I design an effective model?
Now that my brain gets what a model is, my cerebrum proudly tells me that “the model that is more close to its real-world representation should be the effective one”, right? right?
It is utterly wrong. In fact, it is a paradox to think that way.
“As a model of a complex system becomes more complete, it becomes less understandable”
The less information a model carries about its subject, the less useful it will be in helping someone understand that subject. On the other side, the more information a model holds about its subject, the less useful it will be in helping someone understand the subject because the complexity of the model is as high as the subject.
So, what is Effective Modelling?
Bonini’s Paradox demonstrates that you can’t make a useful and accurate model. The trade-off between accuracy and usefulness determines the effectiveness. The key to making a trade-off resides in understanding the purpose.
All models have a purpose, and an effective model contains only the details needed to fulfil its purpose. The notion of abstraction allows us to handle complexity by omitting unnecessary details and leaving only what’s required for solving the problem at hand. In general, abstraction has a connotation that abstraction means vague. But, the right abstraction does not remove necessary information nor produces noise by leaving what’s not required.
“The purpose of abstracting is not to be vague but to create a new semantic level in which one can be absolutely precise.”
Let’s see one more example of a model before diving into effective software modelling in practice.
Okay, I will let you guess what you see in below picture…
Yes, it is just a piece of cardboard. But, I say it’s a model. It’s a model of the Bosch SMS66GW01I dishwasher.
You may say the piece of cardboard doesn’t look anything like that dishwasher. It has no door or racks, and even its colour is different. As we’ve discussed, a model is not supposed to copy a real-world entity. Instead, it should have a purpose — a problem it is supposed to solve. Hence, the right question to ask is, what problem does this model solve?
The problem it solves is checking whether the dishwasher can fit through the utility door. The cardboard can be cut precisely to the size of the dishwasher’s width and depth to test that. Despite the cardboard not looking anything like the dishwasher, it can be extremely useful if we had to decide whether to buy this model or opt for a smaller one.
Building a 3D model of the dishwasher would be a fun project. But, would it solve the problem any more efficiently than the cardboard? No. In software engineering terms, building a 3D model of the dishwasher is overengineering.
In summary, You can’t build a model without specifying its purpose — its boundary. Understanding the problem space — domain — is the key to building an effective model. Let’s talk about Ubiquitous Language and Bounded Context in the next part of the blog along with DDD patterns for modelling business.
“It’s developers’ (mis)understanding, not domain experts’ knowledge, that gets released in production”
