Ubiquitous language - term for developers and users

Question

Our project's team members are a big fans of Ubiquitous Language concept from the Domain-Driven Design Community.

And here is the problem we've found:

Non-techy users like to use a simplified names of all the concepts, they don't want to know all the details, and that's OK. But we can't do the same in code, because this concepts aren't as easy as we represent them to users.

Example: User can setup a project and choose any template for it. But under the hood - it is a concept of the Vendor1's Framework, which is third-party component to our software.

So we, as developers can be confused by users' use of the "template" term. Because we already are used to use "template" term in the area of our MVC framework.

The temporary solution we have now is:

• show simple terms for users
• use real terms in code
• explain user terms-to-code terms translation vocabulary in wiki

How should we solve this problem?

Answer 1

Use simple names when talking with domain experts. Use the same simple names and concepts when implementing domain model. Implement the same simple requirements in domain model that are asked. There shouldn't be something that's implemented in domain model but domain experts have never heard about that.

Use fancy and techy stuff outside in other layers. If you use 3rd party tools - use them there not directly into domain model.

Answer 2

A little late answering here...

You've clearly got a problem of 'overloaded terms' here, where every 'template' is different, yet valid in the appropriate context.

My approach would be:

1. Make everyone aware that "Template" has different meanings in different contexts. This is critical if an individual has to deal with different contexts.

2. Prefix the word "Template" whenever you're using it. E.g. use "MVC template", or "[vendor] template", or "[domain] template". All artefacts (code/documentation) are clear and concise, without having to refer to translation documents.

3. Emphasis clarity over simplicity (especially if attemping to make things 'simpler' causes problems)

Answer 3

You could use as well context mapping to define different contexts and their boundaries. Also, you can separate the domain and the code using modeling(DSLs, UML profiles,...) and bring them back through model driven approaches(e.g. code generation). Actually the point of Ubiquitous Language is to solve these conflicts, so you should find some sort of consensus.