# 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*.

<!--
Guidance: How to use this template
- One glossary per bounded context. The same word may mean different
  things in two contexts; record both, each in its own glossary.
- Terms must be used in conversation, documents, tests and code alike. If
  the code uses another name, either rename the code or change the term.
- Write definitions with domain experts, in their words, not as database
  field descriptions.
- Keep the file in the repository of the context so changes are reviewed.
-->

| Field | Value |
|---|---|
| Bounded context | [Billing] |
| Language owner | [@domain-expert] and [@tech-lead] |
| Version | [0.1] |
| Last reviewed | YYYY-MM-DD |

## 1. Terms

<!-- Guidance: Keep definitions to one or two sentences. Add a concrete example for every term that people have confused. "Synonyms to avoid" lists the words that must not be used for this concept in this context. -->

| 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

<!-- Guidance: Words that mean something different elsewhere. These are where integration bugs come from; translation happens at the boundary. -->

| 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

<!-- Guidance: Agree these rules once; they keep the glossary trustworthy. -->

1. 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.
2. Each change is approved by the language owner and one domain expert.
3. A renamed term is renamed in code, tests, APIs (with deprecation) and
   documentation within [two sprints]. The old term moves to "Synonyms to
   avoid".
4. Terms are never deleted silently; a retired term stays with the note
   "Retired YYYY-MM-DD, replaced by [term]".
5. Disagreement about a definition is a signal of a hidden boundary. Raise
   it at the next modelling session instead of averaging the meanings.
6. The glossary is reviewed every [quarter] against recent tickets and code.

## 4. Change log

<!-- Guidance: Record additions, renames and retirements. -->

| 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.