Heroes of DDD: Holy Grail of the “good” model?

This content originally appeared on DEV Community and was authored by Mateusz Nowak

Cover: https://www.youtube.com/watch?v=DzWUt2GSZ6g

🗿 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.

The model is applicable only in defined context and useful for certain purpose.

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 present are not a Holy Grail that will save every project. 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. 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.

At least you know where to search.

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.

This content originally appeared on DEV Community and was authored by Mateusz Nowak