12. Glossary¶
Help: The most important domain and technical terms that your stakeholders use when discussing the system.
You can also see the glossary as a source for translations if you work in multi-language teams.
Motivation: You should clearly define your terms so that all stakeholders: - Have an identical understanding of these terms - Do not use synonyms and homonyms - Can communicate effectively without misunderstanding
Form: A table with columns for Term and Definition. Potentially more columns for translations into other languages and for references to definitions in external resources.
Tips: - Keep the glossary sorted alphabetically - Include both domain-specific and technical terms - Reference authoritative sources where applicable - Update the glossary as new terms emerge during the project - Consider creating separate sections for domain terms and technical terms
Domain Terms¶
| Term | Definition | Synonyms | Reference |
|---|---|---|---|
| \<Term A> | \<Clear, concise definition of this domain term> | \<Any synonyms used> | \<Link to authoritative source> |
| \<Term B> | \<Clear, concise definition of this domain term> | \<Any synonyms used> | \<Link to authoritative source> |
| \<Term C> | \<Clear, concise definition of this domain term> | \<Any synonyms used> | \<Link to authoritative source> |
| \<Term D> | \<Clear, concise definition of this domain term> | \<Any synonyms used> | \<Link to authoritative source> |
| \<Term E> | \<Clear, concise definition of this domain term> | \<Any synonyms used> | \<Link to authoritative source> |
Technical Terms¶
| Term | Definition | Context |
|---|---|---|
| \<ADR> | \<Architecture Decision Record - a document capturing an important architectural decision along with its context and consequences> | \<Section 9> |
| \<API Gateway> | \<A server that acts as a single entry point for API requests, providing cross-cutting concerns like authentication, rate limiting, and routing> | \<Section 5, 7> |
| \<ATAM> | \<Architecture Tradeoff Analysis Method - a systematic approach for evaluating software architectures relative to quality attribute goals> | \<Section 10> |
| \<Bounded Context> | \<A central pattern in Domain-Driven Design that defines the boundary within which a particular domain model is defined and applicable> | \<Section 8> |
| \<Circuit Breaker> | \<A design pattern that prevents cascading failures by monitoring for failures and temporarily stopping calls to a failing service> | \<Section 6, 8> |
| \<CQRS> | \<Command Query Responsibility Segregation - a pattern that separates read and write operations into different models> | \<Section 4> |
| \<Event Sourcing> | \<A pattern where state changes are stored as a sequence of events, allowing reconstruction of state at any point in time> | \<Section 4, 8> |
| \<HPA> | \<Horizontal Pod Autoscaler - a Kubernetes resource that automatically scales the number of pods based on observed metrics> | \<Section 7> |
| \<ISO 25010> | \<International standard for software product quality models, defining quality characteristics like performance, security, and maintainability> | \<Section 10> |
| \<RPO> | \<Recovery Point Objective - the maximum acceptable amount of data loss measured in time> | \<Section 10> |
| \<RTO> | \<Recovery Time Objective - the maximum acceptable duration of time to restore a system after a disruption> | \<Section 10> |
| \<SLA> | \<Service Level Agreement - a formal agreement defining the expected level of service> | \<Section 7, 10> |
Abbreviations¶
| Abbreviation | Full Form |
|---|---|
| \<API> | \<Application Programming Interface> |
| \<CI/CD> | \<Continuous Integration / Continuous Delivery> |
| \<DDD> | \<Domain-Driven Design> |
| \<HA> | \<High Availability> |
| \<IaC> | \<Infrastructure as Code> |
| \<JWT> | \<JSON Web Token> |
| \<K8s> | \<Kubernetes> |
| \<OIDC> | \<OpenID Connect> |
| \<PII> | \<Personally Identifiable Information> |
| \<RBAC> | \<Role-Based Access Control> |
| \<REST> | \<Representational State Transfer> |
| \<TLS> | \<Transport Layer Security> |
Based on the arc42 architecture template (https://arc42.org).
Created by Dr. Peter Hruschka and Dr. Gernot Starke.
Licensed under CC BY-SA 4.0.