Ubiquitous Language Glossary Template (DDD)
Glossary of domain terms per bounded context with synonyms to avoid, examples, code names, owners and change rules
Anleitung: Use it for each bounded context once domain experts and developers start using shared terms. Fill the ten most confused terms first, with examples. The main pitfall is writing database field descriptions instead of definitions experts would sign off.
Vorschau
Ubiquitous Language: [Bounded context name]
Glossary of the shared language used by domain experts and developers inside one bounded context, with the rules for changing it. Based on the ubiquitous language concept of Domain-Driven Design (Eric Evans). Replace every
[bracketed]value and every row marked Example.
| Field | Value |
|---|---|
| Bounded context | [Billing] |
| Language owner | [@domain-expert] and [@tech-lead] |
| Version | [0.1] |
| Last reviewed | YYYY-MM-DD |
1. Terms
| Term | Definition | Synonyms to avoid | Example | Code name | Owner |
|---|---|---|---|---|---|
| Example: Invoice | A legal request for payment issued to a customer for one billing period | Bill, statement | Invoice INV-2026-0412 for March | Invoice | @billing-expert |
| Example: Billing period | The calendar month for which usage is charged | Cycle, term | 1 to 31 March | BillingPeriod | @billing-expert |
| Example: Credit note | A document that reduces the amount owed on an issued invoice; invoices are never edited | Refund, correction | Credit note for a duplicate charge of 49.00 | CreditNote | @finance-lead |
| Example: Account | The paying customer entity that receives invoices; not a login | User, customer login | Account ACC-3391 with three users | BillingAccount | @billing-expert |
| Example: Dunning | The sequence of reminders after an invoice is overdue | Chasing, collections | Reminder on day 7, 14 and 30 | DunningProcess | @finance-lead |
| [Term] | [Definition] | [Words not to use] | [Concrete example] | [Class or module] | [@owner] |
2. Same word, other contexts
| Term | Meaning here | Meaning in other context | Other context |
|---|---|---|---|
| Example: Account | Paying entity | A person's login | Identity |
| Example: Product | A priced plan line on an invoice | A feature bundle shown in the shop | Catalogue |
| [Term] | [Here] | [There] | [Context] |
3. Rules for evolving the language
- A new term is added when domain experts use it repeatedly and it has no existing equivalent. It is proposed by pull request to this file.
- Each change is approved by the language owner and one domain expert.
- A renamed term is renamed in code, tests, APIs (with deprecation) and documentation within [two sprints]. The old term moves to "Synonyms to avoid".
- Terms are never deleted silently; a retired term stays with the note "Retired YYYY-MM-DD, replaced by [term]".
- Disagreement about a definition is a signal of a hidden boundary. Raise it at the next modelling session instead of averaging the meanings.
- The glossary is reviewed every [quarter] against recent tickets and code.
4. Change log
| Date | Change | Approved by |
|---|---|---|
| YYYY-MM-DD | Example: Renamed "Refund" to "Credit note" | @finance-lead |
| YYYY-MM-DD | [Change] | [@name] |
Standard and licence note
Based on the ubiquitous language concept from Domain-Driven Design (Eric Evans, 2003). All text and examples are original to this collection. Template licence: MIT.
Ähnliche Vorlagen
Architecture Decision Record Template (Tyree-Akerman, Y-Statement)
Detailed ADR – Tyree & Akerman fields (assumptions, constraints, positions, argument, implications, related items) plus Y-statement
Architektur & SystemdesignAPI Versioning and Deprecation Policy Template
API lifecycle policy: versioning scheme, compatibility promises, breaking changes, timelines, Deprecation and Sunset headers
Architektur & SystemdesignAPI Design Guidelines Template (Company Style Guide)
Company API style guide: naming, methods, status codes, RFC 9457 errors, pagination, versioning, security, webhooks, governance