10

A core part of Domain Driven Design is the consistent use of a ubiquitous language across the system - in conversations, code, database schema, UI, tests, etc.

I'm involved in a project in which there is a well-established domain language already, defined by an international standards organisation.

However, the work we're doing is for a public web site, and the 'correct' terms for the domain aren't necessarily how the public typically use and understand them.

The compromise we're using at the moment is to use the 'official' terms everywhere, except for in our acceptance criteria which refer to UI components, where we use the informal names.

Does this seem like a reasonable approach?

Andy Waite
  • 510
  • 2
  • 9
  • Can you supply an example? I could give a more detailed answer then. Do you need to circumscribe terms for them or are there colliding terms with total different meanings? Would it at all be possible to find a common ground between the informal terms and the domain language? – Falcon Sep 22 '11 at 20:33
  • 1
    It's been a while since I read that part of Evans book, but I thought the ubiquitous language was to be used with the domain expert? I certainly wouldn't expect a user to understand all the terminology of the domain expert so I'd only present to the user what you've dubbed the informal names. – Kaleb Pederson Sep 23 '11 at 00:13

2 Answers2

7

Yes, that seems reasonable. If the intended audience does not understand the terms of your language or misinterprets them, then the usability for the enduser takes precedence.

A program or content that a typical user does not understand is of little value. More so, if you only want to present them a simplified tip of an iceberg because they are not and never will be domain experts.

Normally, when you talk about the domain during development then everyone understands the language because it is accurate and all people are within the domain. But if business value is created by communication of content to outsiders of the domain, then do this as simple as possible. Use wordings and languages which are the least likely to be misunderstood and use them in the UI.

Keep the accurate language in your code and for communicating with people who are concerned with the domain. These are the people who have the specs and who are the key users of the applications, the ones with whom you discuss the business logical details. In the rare case that you really discuss most of the business logical details with users who don't have much of a clue about the domain and you needn't dive deep into it, then incorporate their language in your domain language, given that they have a common, unambiguous language at all (which probably isn't the case).

But do make sure that the frontend devs know about your informal terms and their corresponding domain terms.

Falcon
  • 19,248
  • 4
  • 78
  • 93
1

I think the easiest way to answer this would be to draw line exactly where you would draw it if you were presenting the UI in a completely different language.

If your end users needed to see things in Sanskrit, how would you bridge the difference between the UI and the code (and other internal communication).

John Fisher
  • 1,795
  • 10
  • 12
  • Well said. This points up the "Humpty-Dumpty Problem": words are not just a substitution, they refer to things that people know about independently of the words and their use. Animals understand the idea of 'temperature' for example. We get hung up on words, when they are just symbols for concepts. The concepts are the important things. –  Mar 22 '17 at 18:25