Jan Willem Tulp’s blog

Domain Driven Design is not a technology or a methodology. It is a way of thinking and a set of priorities, aimed at accelerating software projects that have to deal with complicated domains. To accomplish that goal, teams need an extensive set of design practices, techniques and principles.

One of the most important concepts of Domain Driven Design is Ubiquitous Language. If you read Eric Evan’s book Domain Driven Design, tackling complexity in the heart of software, he describes the Ubiquitous Language pattern problem definition as follows:

A project faces serious problems when its language is fractured. Domain experts use their jargon while technical team members have their own language tuned for discussing the domain in terms of design. The terminology of day-to-day discussions is disconnected from the terminology embedded in the code (ultimately the most important product of a software project). And even the same person uses different language in speech and in writing, so that the most incisive expressions of the domain often emerge in a transient form that is never captured in the code or even in writing. Translation blunts communication and makes knowledge crunching anemic. Yet none of these dialects can be a common language because none serves all needs.

And as a solution for this, Evans proposes the following:

Therefore, use the model as the backbone of a language. Commit the team to exercising that language relentlessly in all communication within the team and in the code. Use the same language in diagrams, writing, and especially speech. Iron out difficulties by experimenting with alternative expressions, which reflect alternative models. Then refactor the code, renaming classes, methods, and modules to conform to the new model. Resolve confusion over terms in conversation, in just the way we come to agree on the meaning of ordinary words. Recognize that a change in the UBIQUITOUS LANGUAGE is a change to the model. Domain experts should object to terms or structures that are awkward or inadequate to convey domain understanding; developers should watch for ambiguity or inconsistency that will trip up design.

Domain Driven Design, Tackling Complexity in the Heart of Software by Eric Evans

Evans considers the concept of Ubiquitous Language as one of the most fundamental ones in Domain Driven Design, a means to discover and evolve a Domain Model. He tells a bit more about using language in the Part III of his book: ‘Refactoring Toward Deeper Insight’. He explains how one can make implicit concepts explicit by listening to language, scrutinize awkwardness, contemplate contradictions, and how to model less obvious kinds of concepts like constraints, policies and processes. Although he does good job describing how he refines language to improve the model, this part of using language to improve the model can be deepened some more: to get more grip on the process of using language. And one way to do that is by looking at the Meta-Model of Neuro Linguistic Programming (NLP).

Neuro Linguistic Programming (NLP) is a theory of language, communication and thought together with an associated therapeutic method, which holds that people can improve the way they interact with the world by means of certain principles and techniques concerned with their use of language. Although some consider NLP to be controversial, it does provide some useful models and techniques that can help to communicate more effectively. One of the models in NLP is the Meta-Model. The Meta-Model is a linguistic model that was developed by analyzing and modeling highly effective therapists for their linguistic abilities to gather high quality information by asking powerful questions. The idea behind the Meta-Model is that in our mind we have a richer model of the world than we can possibly express in our language. So as we communicate, we always distort, generalize and delete parts of the model that we have in our mind, and so the language we use expresses only parts of our ‘model of the world’ we would like to communicate. The Meta-Model consists of 12 language patterns that restore these distortions, deletions and generalizations. Although you may find some of them more applicable to the field of Domain Driven Design than others, they are quite useful in everyday communication whatsoever. Either way, I believe that being aware of these language patterns, and being able to recognize them, and ask the right questions, will help you as a software developer in the field of Domain Driven Design to create a better, and especially a more useful Domain Model.

The following are the basic Meta-Model language patterns:

DISTORTIONS

1. Nominalization

Nominalizations refer to those kinds of nouns that originated as a process, and have changed into static events. For example, if a domain expert in the field of technical drawings tells you: “A drawing review must be approved by a manager”, then a “review” is a nominalization: it is a process turned into a static event. To recover the deleted information, you can turn the noun back into a verb and ask: “How do you review?”. So, be aware of nouns that are actually processes!

2. Mind Reading

We engage in mind reading when we think and assert that we know the thoughts, motives, intentions, etc. in another’s mind. If you notice yourself, or someone else saying “I know exactly what you mean”, realize that this could be a mind read. In Domain Driven Design, if you’re working on a banking application, and a domain expert says the word “Account”, and you think “I know what he means, because I have a bank account myself”, realize that you’re mind reading, because for a domain expert an Account can be much more than you may be aware of. So get your definitions straight, and question the source of the assumption you or someone else has!

3. Cause-Effect

If you hear someone saying that one thing causes another (even things like “you make me mad”), you have encountered a cause-effect statement. Usually you can recognize them by words like ‘make’, ‘if…then’, ‘as you…’, ‘then’, ‘because’, and almost any present tense verb. If a domain expert tells you that “creating a new account raises our index level”, you’re dealing with a cause-effect statement. To recover the missing information, ask about the process, so “how exactly does creating a new account cause a raise in your index level?”.

4. Complex Equivalence

In a strictly NLP sense, a Complex Equivalence is generated when we use a part of an experience (an aspect of the external behavior) to become equivalent to the whole of its meaning (our internal state). Trigger words to look for are words that utilize equations, like: ‘is’, ‘that means’, ‘equals’, etc. A domain expert might tell you that “opening a document means that you are a publisher”. This is an example of a complex equivalent statement To get to a deeper level of understanding, ask for example “how does opening a document make you a publisher?”, or you could ask for an opposite: “can I open a document without being a publisher”. So, be aware of concepts or processes hidden by equations in language.

5. Presuppositions

The term presupposition refers to the conceptual an linguistic assumptions that have to exist in order for a statement to make sense. By definition, presuppositions are not stated, they operate rather as the supporting foundation or context of a given statement. Trigger words that might be used are ’since’, ‘when’, ‘if’, etc. So, if a domain expert tells you “When a registered user posts a new message, he will receive an alert”, the presupposition is made that users can register. So, be aware of the context, statements and presuppositions that are not spoken, but have to be true in order for the rest of the statement to make sense.

GENERALIZATIONS

6. Universal Quantifier

A universal quantifier refers to the set of words that make a universal generalization. Listen for trigger words like ‘all’, ‘never’, ‘every’, ‘always’, ‘none’, etc. These words leave no room for exceptions, even though there may actually be exceptions. For example, if a domain expert tells you: “none of the user is allowed to modify account data”, you can challenge the universal quantifier by restating the universal quantifier in a question: “really, none of the users?”. And perhaps the domain expert tells you that administrators are allowed to change account information. So, ask again if you hear a universal quantifier.

7. Modal Operator

This linguistic distinction refers to our mode whereby we operate in the world, or where the domain experts believes the domain operates. We can operate by law (should, must, have to), or by opportunity (possible, possible to, can), or by obligation (ought, should), or by empowerment (dare, want to, desire to). In other words, these model operators define the boundaries of our model of the world and our style of operation, or in case of Domain Driven Design, the beliefs of a domain expert about the boundaries, restrictions and possibilities of the domain. You can recover causes or modes of operation by challenging the modal operator. So, if a domain expert says “as a user you can’t change your user name”, you can challenge the modal operator “can’t” by challenging it with “what would happen if a user could change its user name?”. This might reveal hidden information about policies, processes or concepts that determine business rules with regards to user rights, user name usage, etc. So, listen for modal operators, and challenge the statements of the domain expert.

8. Lost Performative

When we perform upon our world with value judgments, we speak about important values that we believe in. But in a lost performative we have stated a value judgment while deleting the performer (speaker) of the value judgment. So, if a domain expert explains “it is really important that we keep track of account usage”, the domain experts deletes the performer of the value judgment that “it is really important”. To challenge this, ask “says who?”, or “according to whom is it important?”. This may allow you to discover more hidden concepts of the domain. So, always make sure that it is clear who makes value statements (and why!).

DELETIONS

9. Simple Deletions

A simple deletion occurs when the communicator leaves out information about a person, thing or relationship. Especially short statements like “this is a difficult part of the system”, or “I don’t feel comfortable with this solution”, or “I am confused”, etc. Just ask for more details to recover the deletions.

10. Comparative Deletions

In a comparative deletion someone makes a comparison, but deletes either the specific persons, things or items compared, or the standard by which the speaker makes the comparison. Listen for trigger words like ‘better’, ‘best’, ‘further’, ‘nearer’, ‘closer’, ‘faster’, etc. A domain expert might tell you that “it is better to have multiple accounts”. To challenge this, ask “better than what?”, or “better according to what standard?”. So, listen closely if all the information in a comparison is given.

11. Lack of Referential Index or Unspecified Nouns and Verbs

Referential Index refers to the person or thing that does or receives the action from the verb in the statement. When a sentence lacks a referential index, it fails to specify by name, term, or phrase that it references, whom it speaks about. Listen for worlds like ‘one’, ‘they’, ‘nobody’, and ‘this’. So, if a domain expert tells you that “they don’t really work with authorized accounts”, make sure you know who ‘they’ are, or ask “who specifically don’t really work with authorized accounts?”. When you listen to a domain expert, make sure you know who or what he is referring to.

12. Unspecified Verb

Unspecified Verbs describe vague, non-specific action. Words like ’show’, ‘demonstrate’, ‘concern’, ‘develop’, etc. certainly describe a process, set of events, experience or action, but these words itself leave out much of the specific information about the action so that we cannot make a clear representation in our mind about the action, and thus we cannot turn it into a useful Domain Model. If a domain expert says: “… and then show an error message”. Does he mean a pop-up message, or do you need to send an email, a log-message, just a message on the screen, etc. To challenge the unspecified verb, ask for the specifics: “what specifically do you mean by ’show’?”. So, make sure that you make vague processes and actions clear so that you can model them.

These are the basic Meta-Model language patterns in NLP. As you listen for trigger words, and start to learning to recognize these language patterns, and you become more proficient in challenging them, your domain model will become much more useful. These patterns allow you create a useful and explicit Domain Model that minimizes vagueness and ambiguities and helps reveal hidden concepts, processes, actions and events.

Currently I am preparing a workshop on Domain-Driven Design to inspire my colleagues to have certain principles in their head when working on software projects. This is quite a challenge, since it is not just a set of steps to follow, but a way of thinking, a mindset. According to the definition of the Domain-Driven Design website, Domain-Driven Design is:

Over the last decade or two, a philosophy has developed as an undercurrent in the object community. The premise of domain-driven design is two-fold:

• For most software projects, the primary focus should be on the domain and domain logic; and
• Complex domain designs should be based on a model.

Domain-driven design is not a technology or a methodology. It is a way of thinking and a set of priorities, aimed at accelerating software projects that have to deal with complicated domains. To accomplish that goal, teams need an extensive set of design practices, techniques and principles.

The key concept of the workshop is: “focus on the Domain Model”. When software developers are developing a software application, I want them to remember this workshop, and be triggered of this core concept of Domain-Driven Design. According to Wikipedia, the definitions are:

• Domain: a field of study that defines a set of common requirements, terminology, and functionality for any software program constructed to solve a problem in that field.
• Model: a pattern, plan, representation (especially in miniature), or description designed to show the main object or workings of an object, system, or concept.

Now these definitions do cover the meaning quite well, but it is not very sticky. They’re rather abstract and conceptual. So, just giving these definitions is probably not enough to have a vibrant memory of the core concept of the workshop. It will stick much better if it is simple, unexpected, concrete, credible, emotional and has some story (I highly recommend you read Made to Stick).

Now, my idea does not necessarily comply with all of those, but do you think software developers will remember to think of the (Domain) Model when they see this?