Early in the days of the agile movement, there was a method named eXtreme Programming (XP) that included the starts of a domain language.

A system metaphor…(is a) story that everyone – customers, programmers, and managers – can tell about how the system works.

Kent Beck Extreme Programming Explained (p. 171)

This was a concise way of getting people to start thinking about the system using words that are part of the business. Systems are built around business problems and should use the same nouns and verbs as the business. When designing a financial system, designers should refer to accounts and transactions. With an asset management system, they might refer to orders, assets, contract manager, etc…

Metaphors help build a common vision and start building a domain language.

Domain Languages Matter

Last summer I had the chance to have multiple discussions with someone with memory loss. In one of these talks, the person had difficulty remembering the word for “car”. They said something along the lines of “the metal box with wheels and an engine”. I could figure out that they had meant ‘car’, but they had lost the word. It was very frustrating for the individual.

In modern society, the word ‘car’ is so ubiquitous that it is often one of the first words people learn in there native language. It is when a specific word that is on the tip of our tongue, but we cannot quite remember it, does it become frustrating and difficult to communicate. Words allows us to describe complex ideas quickly and efficiently and without frustration.

However, words are can be messy.

Take for example the word `case`. This has many different meanings depending on the context. Building a legal system, a case refers to a legal proceeding. This type of case may have lawyers, deadline dates, hearings, etc… But case could also be referring to a medical case. These have very different meanings based of the word ‘case’. This context where this word is used broadly defines expectations of the people communicating. There needs to be a shared understanding of the word ‘case’ for there to be meaningful conversations.

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.

Melvin E. Conway (Conway’s Law)

The language we use within systems help to organize how the system behaves and allows for business users to clearly describe how they want a system to work. This involves creating a shared set of nouns and actions, along with the relationship between each of these words. This creates a way for designing a system around the business, Flexible solutions allow businesses to interact with one another and the system in natural ways that are specific to their contexts.

Consistency Matters Too

Having definitions and parts of a domain language are a good start, but using the domain language to build a system takes effort. Much of this effort goes into being consistent throughout the system. Being consistent allows for system developers to focus on business solutions and helps reduce their cognitive load.

For developers to be efficient and agile, consistency within the system allows freedom to not worry about specific details of the system. A system that is consistent is easier to use once you understand the rules.

The more consistent the rules of the system, the easier it is to build and maintain.

This is especially important when building web services for enterprise systems. Using consistent names and constructs allow developers to focus on how things work together and what they represent. These are often stored as common design patterns within a system. These design patterns become a domain language for the writing of the code itself.

Standardization on common verbs is extremely beneficial. For example, using the verbs “get” vs “fetch” consistently can be very helpful for system designers. Maybe ‘get’ refers to retrieving data from a centralized system, but using the word ‘fetch’ means the data is possibly cached and not up to date. Consistency is the key to conveying meaning at high level without having to dive into details.

Consistency improves efficiency.

What Is You Domain Language?

Every one involved in designing a system will inevitably look back at the system they created and see changes that they would have wanted to make. Hindsight is 20/20 and you should use that knowledge now.

While you may not have specifically designed a system metaphor, or a domain language, if you look at your current systems you will probably find both. It may take a little time and effort, but creating a simple metaphor and a rich language for your products will help your system provide more value.