arc42 section 8: Cross-cutting Concepts

Concepts that apply to many building blocks

The document accepts that the read side may show stale data and says where this is tolerable. → Command Query Responsibility Segregation
The conceptual data model contains no database-specific concepts such as indexes, data types or storage details. → Conceptual Data Model
The conceptual model was validated with business stakeholders, and found gaps were recorded. → Conceptual Data Model Preparation for Logical and Physical Models
The conceptual model contains no data types, tables, columns or indexes. → Conceptual Data Model Preparation for Logical and Physical Models
Relationships state cardinality and whether they are mandatory or optional. → Conceptual data model building method
The conceptual model lists entity classes and their relationships without naming any storage technology. → Conceptual, Logical and Physical Data Model
A CRUD matrix shows which processes create, read, update or delete each business data entity. → Data Architecture
The logical data diagram gives each entity a primary key and attributes without database-specific detail. → Data Architecture Diagram Type
Where applications use different formats, a common data model independent of any one application is defined. → Data reusability and standardized access
A Data Entity/Business Function matrix shows which data supports which functions and which function owns which data. → Define Target Data Architecture Method Phase
The logical model names no database engine. → Logical Data Model
Normalization level is stated, with 3NF as the default stopping point unless a measured query says otherwise. → Logical Data Model
The physical model names the target DBMS and follows its naming rules. → Logical vs. physical data model
The physical model names the target DBMS it is designed for. → Physical Data Model
Security is described as a cross-cutting concern: who can do what to which resources, and how this is controlled, monitored and audited. → Additional Architecture Viewpoints (Security, Information, Operational, Development, Process, Evolution)
Section 8 contains only concepts that are relevant to the system, and they are grouped. → Crosscutting Concept
The building block view is present and any data structures appear as building blocks. → Data architecture documentation in arc42
Changes to the documentation are proposed and reviewed through pull requests. → Documentation as Code
The document is short and focused on important or risky topics. → Guidelines for Documentation
If GET requests are used, the diagram source is deflate-compressed and base64-encoded in the URL. → Kroki
Every relationship arrow has a label stating its intent. → Modeling Method
Architecture documentation is stored as plain text under version control next to the code. → Self-Documentation
Recurring substructures across refinements are factored into a crosscutting concept instead of repeated. → Undetected Duplication Antipattern
References from outside an aggregate point only to its root. → Aggregate
Real-world events, such as loading or customs clearance, are recorded as domain events that feed delivery status. → Cargo Shipping Domain Model
Where the reverse direction is needed, the document names a repository query instead of a second navigation link. → Constraining Associations
Each aggregate names exactly one root entity and states the consistency rules it protects. → DDD Building Blocks (Tactical Patterns)
Third-party or external elements are clearly marked in the building block view and shown only where needed. → Deriving System Components from the Domain Model
Integration events sent to other bounded contexts are asynchronous. → Domain Event
The application layer is thin and the key logic sits in the domain layer. → Domain Layer Separation
The model is implemented in software and has a way to evolve over the product’s life. → Domain Model
Application services contain no business logic and only coordinate domain services, repositories, and transactions. → Domain Service
For a large domain, the document splits the model into bounded contexts instead of one unified model. → Domain-Driven Design
Each aggregate has a root that enforces its consistency boundary. → Domain-Driven Design of the Data Model
Entity equality is based on identity only, not on attributes. → Entity
Invariants block changes to entities in terminal states. → Entity Life Cycle
Value objects are immutable and are compared by their attribute values. → Entity and Value Object
The team’s shared language is based on the domain model used in the software. → Iterative Domain Modeling
Modules are grouped by concepts of the domain, not by technical aspects or developer work assignments. → Module
Terms that differ in meaning between groups are identified rather than merged into one. → Ubiquitous Language
Value objects in the model are immutable, and changes create a new object. → Value Object
Concepts like money, ranges or points are modeled as value objects rather than bare primitives. → Value Object
Business or domain models are documented in arc42 section 8. → Business Architecture
Each data entity is mapped to the application or data component that holds it. → Data Architecture Artifact
Each important data element has a named trustee accountable for its quality. → Data Architecture Principle
Each entity in the matrix is linked to business functions using CRUD codes. → Data Entity/Business Function Matrix
Where several roles create the same entity, the document names one owner or describes a split by role ownership. → Data Entity/Business Function Matrix
Every data entity in the catalog has a definition, an owner and a classification level. → Data Entity/Data Component Catalog
Logical and physical data components are kept separate, so the target architecture does not depend on a specific technology. → Enterprise Architecture Meta Model
The EA tool configuration maps each metamodel entity to a component type and each relationship to a typed reference. → Enterprise Architecture Meta Model
The document states which artifacts from the content framework are used, rather than assuming TOGAF prescribes a format. → TOGAF
Technical constraints are listed, with a note on which may be negotiable. → Technology Architecture
The document assigns responsibility for detecting faults and for handling detected exceptions. → Architectural Decisions for Availability
Architecture and coding rules run as automated unit tests in the build. → Architecturally Evident Coding Style
Each tactic named in the document is tied to the single quality attribute it addresses. → Architecture Means
Communication between internal services is asynchronous where possible, or the document explains why not. → Connectors and Distribution
Tests exist that protect refactoring work as a safety net. → Refactoring
The document justifies the canonical model by the number of integrated applications, since it is overkill for only a few. → Canonical Data Model
Security tokens are not embedded in the claim check; the store enforces its own access control. → Claim Check
For event-based flows, the document describes the end-to-end flow somewhere explicit, since it is not visible in program text. → Connector Transparency (Direct vs Indirect Connection)
Where enrichment calls another source through Camel’s Enrich EIP, the document states the producer cache setting. → Content Enricher and Content Filter
Where rules are checked in order, the order is documented, because the first match decides the branch. → Content-based Router
The design states that the replier copies the request ID into the correlation ID field of the reply. → Correlation Identifier
Receivers take the data type from the channel they read, not from the message content. → Datatype Channel
The document states how many delivery attempts are allowed before a message moves to the dead-letter queue, and that the limit leaves room for retries. → Dead Letter Channel
The document states whether routing-table changes at runtime are applied incrementally or replaced as a whole, and how inconsistency is handled. → Dynamic Router
Where SOAP is used, headers and payload are kept separate: headers in the envelope header, content in the body. → Envelope Wrapper
Consumers that compete on one channel are idempotent, and failing messages go to a dead-letter queue. → Event-Driven Consumer
The document names who is responsible for transforming files between formats. → File Transfer
Messages with unknown or unprocessable formats have a defined destination, such as an invalid message channel. → Format Indicator
The document states that receivers must tolerate receiving the same message more than once. → Idempotent Receiver
The document states whether each interaction is synchronous or asynchronous. → Integration
Pattern names used in the document are neutral about technology and product. → Integration Pattern vs. Middleware Technology
If file transfer is used, the document describes how data is transformed between application formats. → Integration Style
Where Remote Procedure Invocation is used, the document acknowledges that callers are blocked during the call. → Integration Styles
The document names a dedicated channel where the receiver puts messages it cannot process. → Invalid Message Channel
Non-messaging applications are connected through a Channel Adapter. → Message Channel
Each filter has a single output channel. → Message Filter
Where one message must go to several recipients, a Recipient List sends a copy to each. → Message Routing
The design states how out-of-order arrivals are buffered and reordered before processing. → Message Sequence
Request messages that expect a reply carry a unique request ID, and replies copy it into a correlation ID. → Message Structure
The choice of a canonical model considers how many applications exchange messages. → Message Translator
The document lists the supported protocol versions, such as MQTT 3.1.1 or 5. → Messaging Protocol Support in Message Brokers
The document names the common target format that all translators produce. → Normalizer
Each API endpoint has a stated role, for example Processing Resource or Information Holder Resource. → Patterns for API Design
Consumers on queue-based channels are designed to be idempotent, because delivery is at least once. → Point-to-Point Channel
For queue services such as SQS, the document states whether short or long polling is used and the wait time. → Polling Consumer
The document states how much each integration choice makes applications depend on each other. → Principles Influencing EAI Pattern Selection
The document addresses the risk that the central manager becomes a performance bottleneck or a point of failure. → Process Manager
Replies carry a correlation ID equal to the ID of the request they answer. → Request-Reply
Replies are matched to requests with a correlation identifier alongside the return address. → Return Address
Where steps can be reversed, the document explains how compensation works for slip-based flows. → Routing Slip
The document states whether recipients are chosen through a Publish/Subscribe Channel or through a Recipient List. → Scatter/Gather
The document states that the broker or messaging provider, not the consumer, performs the filtering. → Selective Consumer
The risk of changing applications that use the shared database is acknowledged. → Shared Database
Where one message must reach several receivers, the document names this one-to-many link. → Software Connector Classification
Where back pressure is needed, the document names the mechanism or standard used. → Stream Connector
Resilience patterns such as Circuit Breaker, Bulkhead or Timeout are named where services communicate. → Synchronous vs. Asynchronous Communication
Consumers are designed to handle duplicate delivery, because the queue is at-least-once. → Timeout-based Delivery
If a service updates a database and sends a message, the document states how both are kept consistent, for example with an outbox. → Transactional Client
The document names the life cycle variant it uses and lists its phases. → BPM Life Cycle
The to-be state of each process is defined in a design step. → BPM Life Cycle
The team uses an automated tool to check soundness, for example by translating models to Petri nets. → BPMN 2.0 Model Quality
Every outgoing flow of an event-based gateway leads to an intermediate catch event. → BPMN 2.0 Notation
The model states who chooses the inner activities at runtime: the engine via an expression, or a job worker. → BPMN Ad Hoc Sub-Process
Each compensation boundary event links to exactly one handler through a directed association, not a sequence flow. → BPMN Compensation Event
Data is connected to activities with data associations, not with sequence flows. → BPMN Data Element
Every throwing link event has a catching link event with the same link name. → BPMN Event
Joins that must wait for concurrent branches use a parallel gateway, not an exclusive join. → BPMN Gateway
The model is checked for deadlocks and lack of synchronization, for example with a BPMN model checker. → BPMN Gateway Mismatch Antipatterns
Process diagrams are modeled in one consistent direction, such as left to right. → BPMN Layout Guideline
Every XOR gateway shows the X marker. → BPMN Layout Guideline
If models are shown on a website, the document states which viewer is used for it. → BPMN Modeling Tool
The document states which BPMN version is used, and execution is only assumed for version 2.0 or later. → BPMN Motivation
Models that are meant to run are precise enough to translate into software process components. → BPMN Motivation
Each multi-instance activity is clearly drawn as parallel (vertical lines) or sequential (horizontal lines). → BPMN Task Marker and Task Type
The document states that process diagrams use BPMN as a notation that business users can read. → BPMN as Modeling Language, Not Method
BPMN is used only for business-process concepts, not for other modeling needs. → BPMN as Modeling Language, Not Method
Timeouts are modeled with interrupting timer boundary events, and reminders with non-interrupting ones. → Boundary Event
Constraints on how processes may change each business object are stated. → Business Object Lifecycle
The diagram uses color for no more than three distinct categories. → Color Coding in BPMN Models
The diagram has been checked in grayscale and stays readable. → Color Coding in BPMN Models
The document states which BPMN elements the models use, and the set stays small. → Core BPMN Element Subset
Swim lanes appear only at the top level, not inside subprocesses. → Core BPMN Element Subset
A reader process that polls a shared store has a timer start event with a date or cycle definition. → Data Exchange between BPMN Processes
Every exclusive gateway has a default flow or conditions that cover all cases. → Deadlock in Process Models
Decision logic sits in a DMN model, not inside the process flow; the process calls it through a business rule task. → Decision Model and Notation
Modeling of decisions starts from a Decision Requirements Diagram. → Decision Model and Notation
Where RPA bridges a legacy system, the document plans its later replacement by APIs or agents. → Degrees of BPM Maturity
No exclusive gateway merges the outgoing flows of a parallel gateway. → Errors in Process Models
The document names the BPMN version used for its process models, for example BPMN 2.0.2 as the current OMG version. → History of BPMN
No exclusive gateway merges flows that were started concurrently by a parallel gateway. → Lack of Synchronization
Each link pair sits within one scope and does not cross a subprocess boundary. → Link Event
Exception paths are modeled, for example with events that interrupt a subprocess. → Process Analysis and Modeling
Data objects are limited to the most important data aspects. → Process Model Complexity
Each message a process waits for names the attribute used to correlate it to the right waiting instance. → Process Model versus Process Instance
The conversion mapping is stated: functions to tasks, events to events, connectors to gateways. → Process Notations Comparison (EPC, BPMN, UML Activity Diagram)
The check was done with a tool, and any reported violations were fixed or explained. → Soundness of Process Models
Exclusive (XOR) splits are used where exactly one path should be taken, such as alternative branches or loop exits. → Structured Process Modeling with Fragments
Exclusive gateways are used as merges only where the incoming branches are alternatives, since they do not synchronize concurrent flows. → Workflow Pattern
No part is shown in more than one composition relationship at a time. → Aggregation vs. Composition
Where diagrams are informal, the document notes that they may deviate from the UML standard. → Barriers to UML Adoption
Every association line states its multiplicity. → Common Class Diagram Modeling Mistakes
Each region has its own initial state and final state. → Concurrent Region
Object diagrams are used to give examples or test cases for the class diagram. → Instance Specification
If a drawing tool is used, the team has a manual way to keep reused elements consistent across diagrams. → Modeling Tool vs. Drawing Tool
Events that must not restart a state or abort its do activity are modeled as internal transitions, not self-transitions. → State Entry, Exit and Do Behavior
Every choice pseudostate has outgoing guards that cover all cases, so at least one is true. → State Machine Diagram
Where an else transition is used, it is the fallback for a source whose other guards can all be false. → State Machine Diagram Modeling Mistakes
Internal transitions are documented somewhere other than as arrows, since diagrams do not draw them. → State Machine Transition
Where several transitions react to the same event, guard conditions are given so it is clear which one fires. → State and Event
The parameter substitutions are listed on the binding arrow, separated by commas. → Transfer Object Pattern as Package Template
Transitions without a trigger are intended as completion transitions, and each has a guard where it should not always fire. → Transition Syntax (Trigger, Guard, Behavior)
Composition (black diamond) is used only where a part belongs to a single owner. → UML Class Diagram Relationship
Every subclass can stand in for its superclass, because each of its instances is also an instance of the superclass. → UML Generalization and Specialization
No interface is shown as instantiated; each is realized by at least one class or component. → UML Interface
The diagrams follow the team’s style guidelines consistently. → UML Modeling Best Practice
Specification diagrams describe interfaces without naming a particular implementation technology. → UML Perspectives: Conceptual, Specification, Implementation
The Rationale gives business benefits and relates to stakeholders and their goals. → Architecture Principle Structure
Each module hides one design decision behind a minimal interface. → Complexity Reduction
Components expose state only through well-defined functions, and their public contracts are stable. → Component Design Principles
Decisions where principles conflict are recorded with their rationale, trade-offs and consequences. → Conflicting Architecture Principles
Where an intermediary (broker, bus, mediator) is used, its added latency and its role as a possible bottleneck are assessed. → Connect or Disconnect
Where modules depend on each other, the document shows how strong that coupling is (loose or tight). → Coupling and Cohesion
At least one change scenario has a measurable limit, such as effort in person-weeks. → Design for Change
The same rules for what belongs together are applied consistently across the system. → High Cohesion
Each module’s interface reveals as little as possible about its internals. → Information Hiding
No component is forced to depend on methods it does not use. → Interface Segregation Principle
Synchronous calls are reviewed for cascading slowdowns when a provider is slow. → Loose Coupling
Module interfaces reveal as little as possible about their inner workings. → Modularity
New behavior is added through new implementations of an existing interface or through plug-ins, not by editing existing code. → Open-Closed Principle
Each element has clear responsibilities and does not mix in unrelated ones. → Relationships Between Architecture Principles
If dependencies are inverted, the document shows business logic at the center with other parts depending on it. → Separation of Concerns
Elements that change most quickly are kept in data, not hard-wired into code. → Shearing Layers
No module groups its parts arbitrarily, such as a catch-all utility module. → Types of Cohesion
Each principle has a memorable name and a brief, direct statement. → Working with Principles
The document states that actions must be traceable uniquely to the acting entity. → Accountability
Quality properties such as security are handled by applying a perspective to each view, not by adding a separate viewpoint for each property. → Architectural Perspective
Security is treated as risk management, not as a yes-or-no state. → Architectural Perspective
The document states which subjects and resources must have a provable identity. → Authenticity
Consumers read provider data tolerantly, taking only the elements they need. → Compatibility
Trust boundaries are defined, and sensitive flows are segmented so only roles and assets that need them can reach them. → Confidentiality
The document separates faults (causes) from failures (visible deviations from the specification). → Fault
The document states fault tolerance as its own quality requirement, separate from availability and recoverability. → Fault Tolerance
Hazard warning is distinguished from operational constraint, risk identification, fail safe and safe integration. → Hazard Warning
Integrity is treated separately from confidentiality, which covers who may access data. → Integrity
Where two systems use different data formats, the document names the translator that converts between them. → Interoperability
The document states which actions must be provable and how, for example with digital signatures. → Nonrepudiation
The document names a trusted third party, such as a certificate authority or time stamping authority, where proof must hold up against disputes. → Nonrepudiation
Contractual commitments (SLAs) are distinguished from internal targets (SLOs). → Recoverability
Threat modeling identifies and prioritizes the relevant attack vectors. → Resistance
External dependencies have a documented way to manage their risks. → Reusability
The document describes the safe state the system enters or returns to after a failure. → Safety
Autoscaling has a maximum instance count and throttling, and dependencies are checked against it. → Scalability
Integrity measures cover authentication, authorization and tamper detection such as digital signatures. → Security
The user interface is separated from the application so interface changes have limited impact. → Usability
The document assesses whether routing all messages through one broker creates a bottleneck. → Broker Pattern
Where control flow runs against the dependency direction, an output port interface in the inner circle resolves it. → Clean Architecture
Any upward communication from a lower layer is handled through callbacks, observers or events, and is documented. → Layered Architecture
The document states whether layering is strict, relaxed or mixed. → Layers Pattern
The document explains how data stays consistent across services without ACID transactions. → Microservices Architecture
The model does not depend on its views, and views observe the model so several screens can show the same objects. → Model-View-Controller Pattern
Subscribers are designed to tolerate messages arriving in any order. → Publish-Subscribe Pattern
The document states how consumers discover services, for example through a registry. → Service-Oriented Architecture
Long-running bulk operations offer a Cancel option that is easy to find and quick to use. → Aggregate Tactic
Each tactic is linked to the model parameters it adjusts, such as coupling, cohesion and cost for modifiability. → Architectural Tactic
Calls between services use timeouts, so clients do not block forever. → Availability Tactic
Where redundancy is used, the document states whether it is active-active, active-passive or a cold spare, and why. → Availability Tactic
Each redundancy choice states its cost and complexity impact. → Availability Tactic Categories
The document states the failure threshold and time period that trip each circuit breaker. → Circuit Breaker
Stored private data is encrypted at rest as an extra layer on top of access control. → Encrypt Data
Energy-saving tactics are listed together with their impact on other quality attributes, such as response time. → Energy Efficiency Tactic
The document states how the system and its building blocks handle errors and exceptions. → Exception Handling Tactic
Exception handling is tied to a detection mechanism such as heartbeat or ping/echo. → Exception Handling Tactic
Where a monitor is used, it is a separate component that observes the health of other parts. → Fault Detection Tactic
Where state updates between components must be atomic, consistent, isolated, and durable, the document says transactions are used. → Fault Prevention Tactic
Where retry is used, the document states that the faults it targets are transient. → Fault Recovery Tactic
Each degradable feature has a documented fallback path, health signal and re-enable logic. → Graceful Degradation
The heartbeat interval is longer than the network round-trip time, and the failure timeout is a multiple of the interval. → Heartbeat
Fault-detection tactics such as heartbeat are named for the monitored processes. → Integrability, Deployability, Testability and Reliability Tactics
The document says how failed backends are detected and avoided. → Load Balancer
Modules that mix non-cohesive responsibilities are identified and split, or the document explains why not. → Modifiability Tactic
The document states who provides service discovery, versioning and access control, and whether the registry is custom-built or a product. → Modifiability Tactics in SOA
Where events differ in importance, the document describes how they are prioritized. → Performance Tactic
The document states how long a pinging component waits for an echo before declaring failure. → Ping/Echo
The document states that the tactic is chosen to lower coupling between modules for modifiability. → Reduce Coupling
The document explains how a new primary is chosen and how requests are redirected, including DNS TTL effects if DNS is used. → Redundant Spare
The retry policy sets a maximum number of attempts and states what happens after the last one. → Retry
Each hazardous operation is guarded by an explicit interlock that checks preconditions and defaults to a safe state. → Safety Tactic
Where a pattern is used, the document says which tactic it realizes. → Security Tactic
The presentation is separated from the rest of the application so later interface changes stay limited in impact. → Usability Tactic
The design says whether the voter is a single point of failure or is triplicated. → Voting