# arc42 section 12: Glossary

Checks for section 12 (Glossary) of an arc42 document.

Important domain and technical terms

- The relationships in the model reflect business processes and rules. → [Conceptual Data Model](https://arc.fuet.ch/concepts/data-architecture/conceptual-data-model.md)
- Business rules and constraints are captured in the model. → [Conceptual data model building method](https://arc.fuet.ch/concepts/data-architecture/conceptual-data-model-building-method.md)
- Indexes, partitioning and tablespaces appear only in the physical model. → [Conceptual, Logical and Physical Data Model](https://arc.fuet.ch/concepts/data-architecture/conceptual-vs-logical-vs-physical-data-model.md)
- Data types are stated for all stored data objects in the physical model. → [Logical vs. physical data model](https://arc.fuet.ch/concepts/data-architecture/logical-vs-physical-data-model.md)
- A named role, such as the product owner or project manager, is responsible for the glossary. → [Publishing the conceptual data model](https://arc.fuet.ch/concepts/data-architecture/publishing-the-conceptual-data-model.md)
- The glossary lists the key domain and technical terms stakeholders use when discussing the system. → [Publishing the conceptual data model](https://arc.fuet.ch/concepts/data-architecture/publishing-the-conceptual-data-model.md)
- The published model and glossary are updated as the team's understanding of the domain grows. → [Publishing the conceptual data model](https://arc.fuet.ch/concepts/data-architecture/publishing-the-conceptual-data-model.md)
- Deeper levels of the building block view exist only where there is real demand for them. → [Characteristics of a Good View](https://arc.fuet.ch/concepts/documentation/characteristics-of-a-good-view.md)
- Documents such as HTML or PDF are built automatically from the text sources by a toolchain. → [Documentation as Code](https://arc.fuet.ch/concepts/documentation/documentation-as-code.md)
- The document separates the system's architecture from the description of it. → [ISO/IEC/IEEE 42010 Architecture Description Model](https://arc.fuet.ch/concepts/documentation/iso-iec-ieee-42010-architecture-description-model.md)
- The glossary lists the key domain and technical terms that stakeholders use when discussing the system. → [arc42 Glossary](https://arc.fuet.ch/concepts/documentation/arc42-glossary.md)
- Glossary terms match the domain model used in the software. → [arc42 Glossary](https://arc.fuet.ch/concepts/documentation/arc42-glossary.md)
- A named person, such as the product owner or project manager, is responsible for the glossary. → [arc42 Glossary](https://arc.fuet.ch/concepts/documentation/arc42-glossary.md)
- Each bounded context owns its model and its database. → [Bounded Context](https://arc.fuet.ch/concepts/domain-driven-design/bounded-context.md)
- The team has agreed on the name of each bounded context. → [Bounded Context Canvas](https://arc.fuet.ch/concepts/domain-driven-design/bounded-context-canvas.md)
- Terms with several meanings, such as Customer or Product, are identified and explained. → [Business Domain Understanding](https://arc.fuet.ch/concepts/domain-driven-design/business-domain-understanding.md)
- The customer requirement, the plan and the actual delivery are kept as separate concepts. → [Cargo Shipping Domain Model](https://arc.fuet.ch/concepts/domain-driven-design/cargo-shipping-domain-model-example.md)
- Each story states its level of detail (overview or detailed). → [Domain Storytelling](https://arc.fuet.ch/concepts/domain-driven-design/domain-storytelling.md)
- Entities contain behavior that enforces their own invariants, not only data. → [Entity](https://arc.fuet.ch/concepts/domain-driven-design/entity.md)
- The aggregate root enforces integrity, and owned objects are reached only through it. → [Entity Life Cycle](https://arc.fuet.ch/concepts/domain-driven-design/entity-life-cycle.md)
- Objects with a life cycle and state transitions that matter to the business are modeled as entities. → [Entity and Value Object](https://arc.fuet.ch/concepts/domain-driven-design/entity-vs-value-object.md)
- The domain model is tied to its implementation in code. → [Iterative Domain Modeling](https://arc.fuet.ch/concepts/domain-driven-design/evolutionary-domain-modeling.md)
- Each module holds a cohesive set of concepts, and the module list tells the story of the system. → [Module](https://arc.fuet.ch/concepts/domain-driven-design/module.md)
- The domain is split into bounded contexts instead of one single unified model. → [Reflecting the Business Domain in the Architecture](https://arc.fuet.ch/concepts/domain-driven-design/reflecting-the-business-domain-in-the-architecture.md)
- Domain terms used in the document match the terms the domain experts use. → [Ubiquitous Language](https://arc.fuet.ch/concepts/domain-driven-design/ubiquitous-language.md)
- Equality of value objects is defined by comparing all attribute values. → [Value Object](https://arc.fuet.ch/concepts/domain-driven-design/value-object.md)
- The capability map has about two to four levels. → [Capability identification and naming](https://arc.fuet.ch/concepts/enterprise-architecture/capability-identification-and-naming.md)
- A matrix maps data entities to the business functions that create and use them. → [Data Architecture Artifact](https://arc.fuet.ch/concepts/enterprise-architecture/data-architecture-artifacts.md)
- Owner and steward roles are distinguished for each entity. → [Data Entity/Data Component Catalog](https://arc.fuet.ch/concepts/enterprise-architecture/data-entity-data-component-catalog.md)
- Each data entity is mapped to the data components that hold it. → [Enterprise Architecture Meta Model](https://arc.fuet.ch/concepts/enterprise-architecture/enterprise-architecture-meta-model.md)
- Capabilities are mapped to the stages of each value stream. → [Operational Value Stream](https://arc.fuet.ch/concepts/enterprise-architecture/operational-value-stream.md)
- Each framework cell describes only one type of thing. → [Zachman Framework](https://arc.fuet.ch/concepts/enterprise-architecture/zachman-framework.md)
- Each epic is split into smaller user stories before implementation starts. → [Epic](https://arc.fuet.ch/concepts/functional-requirements/epic.md)
- Each ARIS view is described at the requirements, design and implementation levels. → [ARIS Process Views](https://arc.fuet.ch/concepts/modeling-bpmn/aris-process-views.md)
- Discovery results are recorded as as-is models with performance baselines. → [BPM Life Cycle](https://arc.fuet.ch/concepts/modeling-bpmn/bpm-life-cycle.md)
- Each Group has a clear label, so readers can tell why its elements belong together. → [BPMN Artifacts (Group and Text Annotation)](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-artifacts-group-and-text-annotation.md)
- Parallel splits are closed by a parallel join that waits for all incoming flows. → [BPMN Core Elements](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-core-elements.md)
- Process models are stored as BPMN XML so tools can exchange them. → [BPMN Motivation](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-motivation.md)
- Diagrams meant for execution name the specific engine they target. → [BPMN as Modeling Language, Not Method](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-as-modeling-language-not-method.md)
- Every colored diagram includes a legend that explains what each color means. → [Color Coding in BPMN Models](https://arc.fuet.ch/concepts/modeling-bpmn/color-coding-in-bpmn-models.md)
- Process steps are labeled with well-chosen, meaningful names. → [Core BPMN Element Subset](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-element-usage-frequency.md)
- Parallel gateways are used where several paths must run at once, and exclusive gateways where data selects one path. → [Process Model versus Process Instance](https://arc.fuet.ch/concepts/modeling-bpmn/process-model-versus-process-instance.md)
- For each composition, the whole is the one that creates and deletes its parts. → [Aggregation vs. Composition](https://arc.fuet.ch/concepts/modeling-uml/composition-versus-aggregation.md)
- Association ends that matter carry a multiplicity such as * or 0..1. → [UML Association](https://arc.fuet.ch/concepts/modeling-uml/association.md)
- Abstract classes are used only for shared characteristics and have no direct instances. → [UML Generalization and Specialization](https://arc.fuet.ch/concepts/modeling-uml/generalization-and-specialization.md)
- Implementation diagrams name the specific technology they describe. → [UML Perspectives: Conceptual, Specification, Implementation](https://arc.fuet.ch/concepts/modeling-uml/uml-views-conceptual-specification-implementation.md)
- Hardware and communication components are covered by the product quality model only as components of the product. → [ISO/IEC 25010 Quality Models and Their Target Entities](https://arc.fuet.ch/concepts/quality-attributes/quality-models-and-their-target-entities.md)
- Security requirements consider Resistance: sustaining operations while under attack. → [ISO/IEC 25010:2023 Product Quality Model Revision](https://arc.fuet.ch/concepts/quality-attributes/iso-25010-2023-revision.md)