# arc42 Glossary

**In short:** The arc42 glossary is section 12 of the template. It lists the key domain and technical terms stakeholders use, so everyone means the same thing by the same word.

## Explanation

Section 12 of arc42 is the glossary. It collects the most important domain and technical terms that stakeholders use when they talk about the system. A stakeholder is anyone with an interest in the system (see the article Stakeholder).

**Why it exists.** Different people often use the same word with different meanings. A written definition closes that gap and gives the project one shared vocabulary.

**Link to ubiquitous language.** Domain-Driven Design calls this shared vocabulary the ubiquitous language (see the article Ubiquitous Language). Fowler, building on Evans, says this language should be based on the domain model used in the software. So a glossary term should match a concept in the code, not just a word used in meetings. The article Domain Model explains that model.

**Keeping it alive.** The language evolves as the team's understanding of the domain grows. The glossary must change with it. arc42 suggests making the product owner or the project manager responsible for the glossary.

**What to put in.** Add the terms your stakeholders actually use. Give each one a clear definition.

## Example

A team builds a system for a library. Developers say "loan" for a book checkout. Staff use "loan" only for borrowing from another library. The glossary lists "loan" with one clear definition, and gives the other case its own term. The code then uses the same names. The product owner updates the entries when staff change how they work.

## Trade-offs

A glossary costs effort to keep current. A stale entry can mislead readers more than a missing one. Naming one responsible person helps, but that person must actually do the upkeep. The glossary also stays useful only while its terms match the domain model and the code.



## Checks

- The glossary lists the key domain and technical terms that stakeholders use when discussing the system.
- Glossary terms match the domain model used in the software.
- A named person, such as the product owner or project manager, is responsible for the glossary.
- The glossary is updated as the team's understanding of the domain changes.

## Related

- [Ubiquitous Language](https://arc.fuet.ch/concepts/domain-driven-design/ubiquitous-language.md)
- [Domain Model](https://arc.fuet.ch/concepts/domain-driven-design/domain-model.md)
- [Domain-Driven Design](https://arc.fuet.ch/concepts/domain-driven-design/domain-driven-design.md)
- [arc42 Architecture Documentation Template](https://arc.fuet.ch/concepts/documentation/arc42-documentation-template.md)
- [Stakeholder](https://arc.fuet.ch/concepts/vision-stakeholders/stakeholder.md)
- [Bounded Context](https://arc.fuet.ch/concepts/domain-driven-design/bounded-context.md)

## Sources

- [12 - Glossary | arc42 Documentation](https://docs.arc42.org/section-12/) — docs.arc42.org, accessed 2026-11-09
- [Ubiquitous Language](https://martinfowler.com/bliki/UbiquitousLanguage.html) — martinfowler.com, accessed 2026-11-09