The Ubiquitous Language

From fowler: Ubiquitous Language is the term Eric Evans uses in Domain Driven Design for the practice of building up a common, rigorous language between developers and users. This language should be based on the Domain Model used in the software - hence the need for it to be rigorous, since software doesn’t cope well with ambiguity.

Evans makes clear that using the ubiquitous language in conversations with domain experts is an important part of testing it, and hence the domain model. He also stresses that the language (and model) should evolve as the team’s understanding of the domain grows.

By using the model-based language pervasively and not being satisfied until it flows, we approach a model that is complete and comprehensible, made up of simple elements that combine to express complex ideas.

…

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.

— Eric Evans

Gerson Sunyé gerson.sunye@univ-nantes.fr

Motivating Example

User

— I want to disable checklists

Example by Nic Wortel

Developer

Ok, I will open an improvement ticket

class ChecklistDefinitionStatusService
{
    public function setVisible($checklistDefinitionId, $visible)
    {
        $this->visible = $visible;
    }
}

$checklistDefinitionStatusService->setVisible(false);

Why is this a problem?

Constant need to translate from the problem (domain) language to the technical language
people use the same term differently without realizing
information is lost in translation, misaligned concepts are used
developed software misses the point
users will have to compensate

Ubiquitous

u·biq·ui·tous: Adjective: present, appearing, or found everywhere. Synonyms: omnipresent
ubiquitous language: A shared language developed by the team - a team composed of both domain experts and software developers.

Characteristics

used everywhere:
- in user stories (post-its, Jira)
- during discussions, backlog refinements, etc.
- in documentation
- in automated tests
used by everyone on the team: developers and domain experts
evolves over time as new concepts are discovered

The Ubiquitous Language

When discussing the domain, and a developer uses a term, and the domain expert uses exactly the same term, they mean precisely the same thing.

Confluence of Terminologies

Everybody uses it

It is used Everywhere

How to develop a ubiquitous language?

discuss and agree on terminology as a team
use one word for a specific concept, and only one concept per word
point out imprecision and contradictions
update the code as the language evolves
avoid the use of acronyms and abbreviations

Antipatterns

Pattern

Create a glossary

glossary: a list of terms in a particular domain of knowledge with the definitions for those terms

Use Feature descriptions

Feature: Disabling a checklist
  In order to quickly find the right checklist
  As an inspector
  I want to disable checklists that are no longer used

  Scenario: Disabling an active checklist
    Given an active checklist
    When I disable the checklist
    Then the checklist should no longer be visible

  Scenario: Disabling a checklist that is already disabled
    Given a disabled checklist
    When I disable the checklist
    Then I should get an error

Use Feature descriptions

Behat, an open source Behavior Driven Development framework

Figure 1. Behat Output

Use Feature descriptions

Figure 2. Behat Failure

Improved Process

Figure 3. New Jira Ticket

class Checklist
{
    public function disable()
    {
        $this->enabled = false;
    }
}

$checklist->disable();

Bounded Contexts

Bounded Contexts: Linguistic Boundary

Give meaning to your software model
Put your all relational models in same linguistic boundary
Define a ubiquitous language