arc42 section 12: Glossary

Important domain and technical terms

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