Model domain in your codebase as a reflection of the reality

Sometimes in software development, we end up with software that lives in its own realm. There is stuff that's weirdly named, entities that have no meaning in the real world and every time we want to add a feature that requires an extension of the model we find limitations, conflicts, and paradoxes. This article tries to describe a practice, how to avoid this situation.

en 14 Oct 2019
Reading time: 1 minute
Design

In software development we solve problems. And the way how we do it is that we simplify reality, we put this simplification into the computer, we solve the problem there (in the context of that simplified version of reality), we apply the results in the real world hoping it will be ok.

We call this simplification of the reality: the model.

The model

It is important to note, that human perception (and understanding) of reality is also just a model. It's is a huge simplification of the actual vast and detailed reality. This mental model lives in our minds and we solve our problems in this mental model, we apply the results in the real world hoping it will be ok. Sometimes it is ok, and sometimes it isn't.

We, humans, communicate our perception of the reality mostly via natural language.

The problem

Every non-trivial software needs to work in an environment where:

  1. The problem is complex and consists of many sub-problems.
  2. There can be multiple problems that we want to solve in the same domain.
  3. The problem(s) can shift in time.

This means our model needs to be flexible and open to extension.

Good design

What "good design" in the context of software development actually means? It is the design that is most useful in solving given problems (keep the previous section in mind). Good design is flexible and open to extension.

Design model as an abstraction of the reality

It is ok and necessary to simplify, but the model must structurally reflect reality.

Never model the meter thick wall of concrete wherein the reality are doors, just because you "needed" to create something "helpful" for solving your problem, but what is not present in the reality you are modeling.

This is not about abstracting for everything. It's about being consistent with the reality on the given level of abstraction.

This allows:

  1. to add more detail later without hard and painful reorganization
  2. to add more of the domain into the model later, we can just connect the dots and plug it in

If the model became inconsistent with reality, then limitations, conflicts, and paradoxes start to appear and it became is extremely hard to extend the software to solve any other problem.

Found typo? Fix me!