ADR 8 - Common Glossary

• ADR 8 - Common Glossary
  • Context
  • Decision
  • Rationale
  • Status
  • Consequences

Context

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.

From Domain-­‐Driven Design Reference

See https://thedomaindrivendesign.io/developing-the-ubiquitous-language/

Decision

We will use a common glossary to define the ubiquitous language as an essential part of the domain model.

Rationale

When we all speak the same language in the project. There is less change of miscommunication or getting lost in translation.

See Martin Fowler’s page on Domain Driven Design.

Also Eric Evans’s 2003 book is an essential read for serious software developers

Status

• Proposed
• Accepted
• Deprecated
• Superseded

If deprecated, indicate why. If superseded, include a link to the new ADR.

Consequences

We must keep a glossary of all terms and definitions in the bounded context the project thus creating an ubiquitous language.

We provided a common glossary template