Last updated on Sep 19, 2024

How do you communicate and enforce the ubiquitous language across different teams and stakeholders in DDD?

Domain-driven design (DDD) is a way of developing software that focuses on the core business problems and the language used to describe them. A ubiquitous language is a common and consistent way of naming and defining the key concepts, rules, and processes in a domain. It helps to bridge the gap between the business and the technical teams, and to avoid ambiguity and confusion. But how do you communicate and enforce the ubiquitous language across different teams and stakeholders in DDD? Here are some tips and practices to help you achieve that.

1 Use context maps

A context map is a visual representation of the relationships and boundaries between different subdomains and bounded contexts in a system. A bounded context is a logical boundary where a specific ubiquitous language applies. A context map helps you to identify and manage the dependencies, interactions, and translations between different bounded contexts. It also helps you to communicate the big picture of the system and the domain to the stakeholders.

Add your perspective

Nadeem Malik

Enterprise Architect - providing enterprise-wide insights, promoting standardization, reducing costs, mitigating risk, increasing agility, realizing strategies, and driving innovation.
Report contribution
Context maps r key for visualizing relationships between subdomains & bounded contexts. They help identify dependencies & translations needed between diff parts of the system. As an EA, I've found context maps invaluable for aligning teams on the big picture & fostering a shared understanding of the domain language. Just remember, they're living documents - keep 'em updated as your system evolves!

Like

2 Use glossaries and dictionaries

A glossary or a dictionary is a document that lists and defines the terms and concepts used in a ubiquitous language. It serves as a reference and a source of truth for the teams and stakeholders involved in a domain. It helps to avoid misunderstandings, inconsistencies, and conflicts in the language. It also helps to onboard new team members and stakeholders to the domain. A glossary or a dictionary should be updated and maintained regularly, and be easily accessible and searchable.

Add your perspective

Nadeem Malik

Enterprise Architect - providing enterprise-wide insights, promoting standardization, reducing costs, mitigating risk, increasing agility, realizing strategies, and driving innovation.
Report contribution
Glossaries & dictionaries are crucial tools for maintaining consistency in ubiquitous language. They act as a single source of truth, helping prevent misunderstandings & conflicts. I've seen teams struggle when these aren't kept up-to-date tho. Pro tip: make your glossary easily accessible & searchable - maybe even integrate it into your dev environment. It's amazing how much smoother things run when everyone's speakin' the same language!

Like

3 Use domain events

A domain event is something that happens in the domain that is of interest to the business or the system. It captures the state change and the context of a business process or a rule. It also communicates the intent and the outcome of an action or a decision. A domain event is expressed in the ubiquitous language, and can be used to communicate and enforce the language across different bounded contexts. It can also be used to trigger or coordinate other actions or processes in the system.

Add your perspective

4 Use code as documentation

Code is one of the most important artifacts in DDD, as it reflects the design and the logic of the system. It is also one of the most effective ways to communicate and enforce the ubiquitous language, as it is executable and testable. Code should be written in a way that is readable, understandable, and consistent with the ubiquitous language. It should use meaningful names, clear structures, and appropriate patterns that match the domain concepts, rules, and processes. It should also be documented with comments, annotations, and examples that explain the intent and the behavior of the code.

Add your perspective

5 Use workshops and reviews

Workshops and reviews are collaborative activities that involve different teams and stakeholders in the domain. They are used to elicit, validate, and refine the requirements, assumptions, and scenarios in the domain. They are also used to share, discuss, and align on the ubiquitous language, and to identify and resolve any gaps, conflicts, or ambiguities in the language. Workshops and reviews can take various forms, such as domain story telling, event storming, example mapping, or code review.

Add your perspective

6 Use feedback loops

Feedback loops are mechanisms that allow you to collect, analyze, and act on the feedback from the users, customers, or other stakeholders in the domain. They help you to measure and improve the quality, usability, and value of the system. They also help you to evolve and adapt the ubiquitous language to the changing needs, expectations, and realities of the domain. Feedback loops can include surveys, interviews, tests, metrics, or experiments.

Add your perspective

Nadeem Malik

Enterprise Architect - providing enterprise-wide insights, promoting standardization, reducing costs, mitigating risk, increasing agility, realizing strategies, and driving innovation.
Report contribution
Feedback loops are essential for keeping your ubiquitous language relevant & effective. They help you gauge how well your language resonates with stakeholders & adapt to changing needs. Consider implementing regular surveys, user interviews, or even A/B tests to gather insights. I've seen projects where neglecting feedback led to a disconnect between the system's language & real-world usage. Remember, language evolves - your ubiquitous language should too!

Like

How do you communicate and enforce the ubiquitous language across different teams and stakeholders in DDD?

1

2

3

4

5

6

1 Use context maps

2 Use glossaries and dictionaries

3 Use domain events

4 Use code as documentation

5 Use workshops and reviews

6 Use feedback loops

Technical Architecture

Rate this article

Thanks for your feedback

More articles on Technical Architecture

More relevant reading