What time can teach us about models

As a trainer and coach at Aardling, I often have to explain what Domain-Driven Design (DDD) is. One of the big concepts of DDD is modelling, and although it’s a straightforward concept to understand, it’s sometimes tricky to define what a model actually is.

Here’s how Eric Evans, author of “Domain-Driven Design: Tackling Complexity in the Heart of Software” describes it:

In other words, a model is:

1. Always an abstraction, it is not an exact replica, and in order to make it usable and useful, we abstract and simplify elements.

2. Made up of carefully chosen aspects of the domain we want to incorporate into the model.

3. Trying to solve a certain problem. It’s not only a representation, it helps us achieve a stated goal.

A good example of a model is a metro map. It’s an abstraction, it’s not the real world. The model includes visualisations of lines, stops and stations; each line has its own colour and name. It’s a schematic representation and it’s useful primarily for someone travelling through the city. It is also a distinctly different model from what a rail track maintenance company would use. They would need to see different things, like precise distances between stations, their current electrification status, and stations not currently in use. But for the purposes of the traveller crossing the city, this type of detail isn’t important.

The metro map example illustrates the core ideas behind what a model is and why it’s useful. More recently I’ve been using another example to demonstrate the value of modelling: Time.

I've learned some core lessons about modelling by using the example of Time. I’m going to unpack these learnings below.

Models are built on models.

A digital calendar like gCal is a model that allows us to manage our time and ensure we don’t have double bookings and so on. But it’s also based on a deeper, underlying model, Time.

Time is an abstraction for something that happens in the physical world that we have to describe, and we attach attributes to it as behaviour. We cannot see time going by but we all acknowledge that it exists, and that helps us reason about it.

Models are imperfect and incomplete

The first inspiration for a model is often based on something observable in the real world. But the interesting thing is that we often simplify them. For example, the rotation of the Earth isn’t the same every day. Some days the Earth rotates a little quicker, some days a little slower, it depends on the season and how close we are to the sun, but we all agree, on average, it's 24 hours. While in reality, it’s sometimes 23 hours and something, and other times 24 hours and something. The same is true for days. One revolution around the sun is not 365 days. It’s more or less 365 and a quarter but we have agreed to ignore that quarter so that it becomes easier to reason about, and easier to think about in normal years.

In this model, we also have a compensation mechanism, which is the leap day. This compensation mechanism ensures we don’t have to think about the details and complexity of the real situation. We can postpone the thinking of those details for more than 1000 days so that only ever 4 years do we need to take one day to compensate for the behaviour of the model towards the real world. A model therefore doesn’t need to be perfect, or perfectly replicated, but the model must be good enough in most cases, and have mechanisms to take care of special situations or exceptions.

Models need new abstractions

Even though the model is based on observable things, the reality might not give enough solutions to actually solve the user’s problem. In the case of Time, we don’t have enough language with just days and years to agree on when to meet with someone. The only observable thing in this context is the height of the sun relative to our surroundings. But people needed more options so we started to introduce new concepts and abstractions. Those things are new abstractions to solve the problem. In this case, in the Near East, the people started to split the day into 10 equal parts plus one part for dawn and one part for twilight, which gave us the basis for the 12 hour day, and the equivalent of the 12-hour night. And even though in the beginning these parts were variable, because they were aligned to the amount of light and the dark, gradually this model evolved to a fixed time, which we called an hour.

Models need terms

Sometimes in order to solve a problem, we must come up new abstractions which don’t exist in the domain yet. But these new abstractions need names. We need to have words and the means to communicate these concepts to describe and use the model. We have to invent and repurpose terminology and language in order to do that. Going back to our example, sometimes we can use words that we already know, like Day and Night, or we can use names found in existing concepts. For example, the word Month in the Germanic language comes from the Moon and aligns with the moon cycle more or less.

Other words come from a different context or were repurposed, like Hour. The origins of the Hour come from “any period of time” but it gradually became more exact and transformed into how we think of the Hour today. And sometimes a word is totally new. The term “Week” originates in being “a series of, " so it has nothing to do with Time. Some of these terms are chosen arbitrarily and that’s very normal. We have found and invented new concepts, and these concepts have needed names, we found inspiration around us in order to start describing and reasoning about these things.

Models evolve over time

When we invent new things, we have to take into account it might not be the best way, so we have to leave scope to reinvent or redefine concepts over time.

One example of that is the leap second. The Earth is gradually slowing down because of tidal forces. Our model of time is therefore actually running behind the physical time. And because we notice that, we need to accommodate it. There is talk now about introducing a leap minute to accommodate this difference.

So even though a model works, there are always new learnings to improve it, and it makes sense to evolve the model over time to make it better.

Models are contextual

Models like Time are contextual. For instance the model I’ve described only applies on Earth. It doesn’t work on another planet. A year on Mars is not 365 days, it’s longer. And even the days are also slightly longer. On Mars, you can build a similar model, one that is based on the same principles, but is different in the details. Models can also depend on culture. The Gregorian calendar is one model, but there are other models in the world based on other times and defined differently that make sense to different people.

Those are my six learnings of what Time can teach us about modelling. I hope this is helpful for you when thinking about your own models.

Stijn Vannieuwenhuyse is a senior consultant and trainer at Aardling. If you’re looking to improve your critical software systems, let’s talk.