# arc42 section 5: Building Block View

Checks for section 5 (Building Block View) of an arc42 document.

Static decomposition into building blocks

- The document explains how the read store is kept in sync with the write store, such as through events. → [Command Query Responsibility Segregation](https://arc.fuet.ch/concepts/data-architecture/command-query-responsibility-segregation.md)
- The conceptual diagram shows only entities and relationships, in terms a business audience understands. → [Conceptual Data Model Preparation for Logical and Physical Models](https://arc.fuet.ch/concepts/data-architecture/conceptual-data-model-preparation-for-logical-and-physical-models.md)
- The logical model is independent of a specific DBMS or storage technology. → [Conceptual, Logical and Physical Data Model](https://arc.fuet.ch/concepts/data-architecture/conceptual-vs-logical-vs-physical-data-model.md)
- The document names the database of record for master and reference data. → [Data Architecture](https://arc.fuet.ch/concepts/data-architecture/data-architecture.md)
- The conceptual data diagram names core business entities and is used to find duplicated data. → [Data Architecture Diagram Type](https://arc.fuet.ch/concepts/data-architecture/data-architecture-diagram-types.md)
- Any denormalization for performance appears only in the physical, database-specific model. → [Data Architecture Diagram Type](https://arc.fuet.ch/concepts/data-architecture/data-architecture-diagram-types.md)
- Shared identity concepts, such as how to identify a customer or listener, are agreed across domains. → [Data reusability and standardized access](https://arc.fuet.ch/concepts/data-architecture/data-reusability-and-standardized-access.md)
- Each entity has a stated identifier, and identifying relationships pass the parent's key into the child's identifier. → [Logical Data Model](https://arc.fuet.ch/concepts/data-architecture/logical-data-model.md)
- The logical model is free of database-specific details and does not depend on a chosen DBMS. → [Logical vs. physical data model](https://arc.fuet.ch/concepts/data-architecture/logical-vs-physical-data-model.md)
- Primary keys, foreign keys, and indexes are defined for data access. → [Physical Data Model](https://arc.fuet.ch/concepts/data-architecture/physical-data-model.md)
- The architecture description uses several views, each aimed at named stakeholders. → [4+1 View Model](https://arc.fuet.ch/concepts/documentation/4-1-view-model.md)
- The document states which building blocks belong to the existing system and which belong to the target. → [AS-IS and TO-BE View](https://arc.fuet.ch/concepts/documentation/as-is-and-to-be-view.md)
- Planned decisions are marked as proposed or accepted, and replaced decisions as deprecated or superseded. → [AS-IS and TO-BE View](https://arc.fuet.ch/concepts/documentation/as-is-and-to-be-view.md)
- Every overview diagram has a title that states its type and scope. → [Architectural Overview Antipattern](https://arc.fuet.ch/concepts/documentation/architectural-overview-antipatterns.md)
- Acronyms and abbreviations are understandable to all intended readers. → [Architectural Overview Antipattern](https://arc.fuet.ch/concepts/documentation/architectural-overview-antipatterns.md)
- The diagram stays abstract and does not disclose implementation details. → [Architectural Overview Diagram](https://arc.fuet.ch/concepts/documentation/architectural-overview-diagram.md)
- Each view states which stakeholders' concerns it addresses. → [Architectural View](https://arc.fuet.ch/concepts/documentation/purpose-of-views.md)
- The documentation includes a building block view of the system's static structure. → [Architecture View](https://arc.fuet.ch/concepts/documentation/architecture-view.md)
- Each view states which stakeholder concerns it addresses. → [Architecture View](https://arc.fuet.ch/concepts/documentation/architecture-view.md)
- Each view is built with the patterns, templates and conventions of a named viewpoint. → [Architecture View](https://arc.fuet.ch/concepts/documentation/architecture-view.md)
- The documentation states which set of viewpoints (view model) it uses, rather than an ad hoc collection of diagrams. → [Architecture View Model](https://arc.fuet.ch/concepts/documentation/architecture-view-model.md)
- Each view in the document is built from a named viewpoint. → [Architecture Viewpoint](https://arc.fuet.ch/concepts/documentation/architecture-viewpoint.md)
- Each component diagram zooms into exactly one container and shows the components inside it with their responsibilities and technology. → [C4 Component Diagram](https://arc.fuet.ch/concepts/documentation/c4-level-3-component-diagram.md)
- The diagram shows the directly connected containers, people, and software systems around the components. → [C4 Component Diagram](https://arc.fuet.ch/concepts/documentation/c4-level-3-component-diagram.md)
- Component diagrams exist only for containers where they add value. → [C4 Component Diagram](https://arc.fuet.ch/concepts/documentation/c4-level-3-component-diagram.md)
- The documentation includes a code-level diagram only for the most important or complex components. → [C4 Level 4: Code Diagram](https://arc.fuet.ch/concepts/documentation/c4-level-4-code-diagram.md)
- Code-level diagrams are generated by an IDE or modeling tool instead of drawn by hand. → [C4 Level 4: Code Diagram](https://arc.fuet.ch/concepts/documentation/c4-level-4-code-diagram.md)
- Each code-level diagram covers a single component and shows code elements such as classes, interfaces or tables. → [C4 Level 4: Code Diagram](https://arc.fuet.ch/concepts/documentation/c4-level-4-code-diagram.md)
- Each container shown is a separately executing or data-storing unit, such as a web app or database, not assumed to be Docker. → [C4 Model](https://arc.fuet.ch/concepts/documentation/c4-model.md)
- Each view or viewpoint names the stakeholders it serves and the concerns it addresses. → [Characteristics of a Good View](https://arc.fuet.ch/concepts/documentation/characteristics-of-a-good-view.md)
- The architecture document contains a building block view, since it is mandatory in arc42. → [Component View](https://arc.fuet.ch/concepts/documentation/component-view.md)
- The building block view is organized as a hierarchy of black boxes and white boxes, each with a description. → [Component View](https://arc.fuet.ch/concepts/documentation/component-view.md)
- Deeper levels zoom only into selected building blocks of the level above. → [Component View](https://arc.fuet.ch/concepts/documentation/component-view.md)
- Building blocks in the view are grouped by responsibility, not named after code packages such as Facade, Service or Dto. → [Component View Antipattern: Lifting Code to Model Level](https://arc.fuet.ch/concepts/documentation/component-view-antipattern-lifting-code-to-model-level.md)
- Level 3 zooms only into selected level 2 blocks, not into every block. → [Component View Antipattern: Lifting Code to Model Level](https://arc.fuet.ch/concepts/documentation/component-view-antipattern-lifting-code-to-model-level.md)
- Code-level detail appears only for the most important or complex components. → [Component View Antipattern: Lifting Code to Model Level](https://arc.fuet.ch/concepts/documentation/component-view-antipattern-lifting-code-to-model-level.md)
- The building block view is a hierarchy of black boxes and white boxes, not a single diagram. → [Component View Refinement Levels](https://arc.fuet.ch/concepts/documentation/component-view-refinement-levels.md)
- Each deeper level zooms into selected blocks of the level above, not into every block. → [Component View Refinement Levels](https://arc.fuet.ch/concepts/documentation/component-view-refinement-levels.md)
- Refined blocks are the important, risky, complex or volatile ones. → [Component View Refinement Levels](https://arc.fuet.ch/concepts/documentation/component-view-refinement-levels.md)
- The container diagram covers a single software system and follows from the system context view. → [Container Diagram (C4 Level 2)](https://arc.fuet.ch/concepts/documentation/c4-container-diagram.md)
- Databases and file systems appear as containers. → [Container Diagram (C4 Level 2)](https://arc.fuet.ch/concepts/documentation/c4-container-diagram.md)
- The solution strategy stays brief and references section 8 for the how and why of approaches. → [Crosscutting Concept](https://arc.fuet.ch/concepts/documentation/arc42-crosscutting-concepts.md)
- The business context shows the system as a black box with domain interfaces to communication partners. → [Data architecture documentation in arc42](https://arc.fuet.ch/concepts/documentation/data-architecture-documentation-in-arc42.md)
- Diagrams meant to stay editable are saved as .drawio.png and were exported with the 'Include a copy of my diagram' option enabled. → [Diagram Metadata in PNG (drawio.png)](https://arc.fuet.ch/concepts/documentation/diagram-metadata-in-png-drawio-png.md)
- Views are generated from one shared model, so the diagrams stay consistent with each other. → [Diagrams as Code](https://arc.fuet.ch/concepts/documentation/diagrams-as-code.md)
- The building block view is present and shows a hierarchy of black boxes and white boxes. → [Essential Architecture Views (Context, Component, Runtime, Distribution)](https://arc.fuet.ch/concepts/documentation/contemporary-essential-views.md)
- Each interface is described in detail in one place, and other places only reference it. → [Guidelines for Documentation](https://arc.fuet.ch/concepts/documentation/guidelines-for-documentation.md)
- Each viewpoint used states which stakeholder concerns it frames. → [ISO/IEC/IEEE 42010 Architecture Description Model](https://arc.fuet.ch/concepts/documentation/iso-iec-ieee-42010-architecture-description-model.md)
- Diagrams are described as views of a model that is kept separate from them. → [Model vs. View](https://arc.fuet.ch/concepts/documentation/model-vs-view.md)
- Every diagram has a title stating its diagram type and scope. → [Modeling Method](https://arc.fuet.ch/concepts/documentation/modeling-method.md)
- Every diagram includes a key or legend that explains its notation. → [Rules of Thumb for Modeling](https://arc.fuet.ch/concepts/documentation/rules-of-thumb-for-modeling.md)
- Interface or API documentation is generated from the source (for example with Javadoc) instead of written separately. → [Self-Documentation](https://arc.fuet.ch/concepts/documentation/self-documentation.md)
- The legend explains shapes, colors, border styles, line types and arrow heads used in the diagram. → [Self-Invented Notation Drawback](https://arc.fuet.ch/concepts/documentation/self-invented-notation-drawback.md)
- The architecture description is split into several interrelated views, not one monolithic document. → [Software Architecture Documentation Consensus](https://arc.fuet.ch/concepts/documentation/software-architecture-documentation-consensus.md)
- If C4 is used, the diagrams follow the hierarchy of system, container, component and code element. → [Software Architecture Documentation Consensus](https://arc.fuet.ch/concepts/documentation/software-architecture-documentation-consensus.md)
- Questions about external systems and users are answered in a context view. → [Stakeholder Questions Addressed in Views](https://arc.fuet.ch/concepts/documentation/stakeholder-questions-addressed-in-views.md)
- Every element in each diagram belongs to the same abstraction level. → [Unclear Level of Abstraction Antipattern](https://arc.fuet.ch/concepts/documentation/unclear-level-of-abstraction-antipattern.md)
- Busy diagrams are split so each one focuses on one or two concerns. → [Unclear Level of Abstraction Antipattern](https://arc.fuet.ch/concepts/documentation/unclear-level-of-abstraction-antipattern.md)
- Each interface or element is described in detail in only one place, and other occurrences reference it. → [Undetected Duplication Antipattern](https://arc.fuet.ch/concepts/documentation/undetected-duplication-antipattern.md)
- Each diagram states its notation, its target audience and its purpose. → [View Creation Method](https://arc.fuet.ch/concepts/documentation/view-creation-method.md)
- The runtime view covers scenarios chosen for their architectural relevance. → [View Creation Method](https://arc.fuet.ch/concepts/documentation/view-creation-method.md)
- Each aggregate names one root object. → [Aggregate](https://arc.fuet.ch/concepts/domain-driven-design/aggregate.md)
- Changes to an aggregate go through methods on the root. → [Aggregate](https://arc.fuet.ch/concepts/domain-driven-design/aggregate.md)
- A context map shows the relationships and integration points between contexts, including external systems. → [Bounded Context](https://arc.fuet.ch/concepts/domain-driven-design/bounded-context.md)
- The purpose of each bounded context is stated in a few sentences of business language, without technical details. → [Bounded Context Canvas](https://arc.fuet.ch/concepts/domain-driven-design/bounded-context-canvas.md)
- Each bounded context is classified as core, supporting, or generic. → [Bounded Context Canvas](https://arc.fuet.ch/concepts/domain-driven-design/bounded-context-canvas.md)
- Entities such as Cargo have a stable identity (for example a tracking id) and a documented life cycle. → [Cargo Shipping Domain Model](https://arc.fuet.ch/concepts/domain-driven-design/cargo-shipping-domain-model-example.md)
- Associations that can only be used in one direction are marked with a traversal direction. → [Constraining Associations](https://arc.fuet.ch/concepts/domain-driven-design/entity-relationship-clarification.md)
- Associations with a key-based lookup show a qualifier that reduces the far-end multiplicity. → [Constraining Associations](https://arc.fuet.ch/concepts/domain-driven-design/entity-relationship-clarification.md)
- Arrows in the map are explained, including which side is upstream and which is downstream. → [Context Map](https://arc.fuet.ch/concepts/domain-driven-design/context-map.md)
- Value objects are immutable and are replaced by new instances when they change. → [DDD Building Blocks (Tactical Patterns)](https://arc.fuet.ch/concepts/domain-driven-design/ddd-modeling-elements.md)
- Building blocks are grouped by cohesion, so things inside one block belong together. → [Deriving System Components from the Domain Model](https://arc.fuet.ch/concepts/domain-driven-design/deriving-system-components-from-the-domain-model.md)
- Domain events are named with past-tense verbs and are immutable. → [Domain Event](https://arc.fuet.ch/concepts/domain-driven-design/domain-event.md)
- The domain layer is described as isolated from the other layers. → [Domain Layer Separation](https://arc.fuet.ch/concepts/domain-driven-design/domain-layer.md)
- Each layer depends only on the layer below it. → [Domain Layer Separation](https://arc.fuet.ch/concepts/domain-driven-design/domain-layer.md)
- The Ubiquitous Language is based on the domain model used in the software. → [Domain Model](https://arc.fuet.ch/concepts/domain-driven-design/domain-model.md)
- Business rules that span several entities or aggregates sit in a domain service, not in an application service. → [Domain Service](https://arc.fuet.ch/concepts/domain-driven-design/domain-service.md)
- Entities keep their own behavior, so the model is not anemic. → [Domain Service](https://arc.fuet.ch/concepts/domain-driven-design/domain-service.md)
- Where terms mean different things to different groups, the document makes the conflicting meanings explicit in separate models. → [Domain-Driven Design](https://arc.fuet.ch/concepts/domain-driven-design/domain-driven-design.md)
- Each bounded context is named and consists of one or more aggregates. → [Domain-Driven Design of the Data Model](https://arc.fuet.ch/concepts/domain-driven-design/domain-modeling-procedure.md)
- Each entity has a defined identity, and the document states what counts as the same entity. → [Entity](https://arc.fuet.ch/concepts/domain-driven-design/entity.md)
- State changes are named methods that reject invalid transitions immediately. → [Entity Life Cycle](https://arc.fuet.ch/concepts/domain-driven-design/entity-life-cycle.md)
- Each entity in the model has an identity that stays the same through its life. → [Entity and Value Object](https://arc.fuet.ch/concepts/domain-driven-design/entity-vs-value-object.md)
- Module names appear in the glossary and the team uses them as part of its shared vocabulary. → [Module](https://arc.fuet.ch/concepts/domain-driven-design/module.md)
- Terms that stakeholders understand differently, such as Customer or Product, are identified and their meanings are written down. → [Reflecting the Business Domain in the Architecture](https://arc.fuet.ch/concepts/domain-driven-design/reflecting-the-business-domain-in-the-architecture.md)
- Application descriptions do not depend on particular technologies. → [Application Architecture](https://arc.fuet.ch/concepts/enterprise-architecture/application-architecture.md)
- Interfaces between applications are documented, and communication views stay logical. → [Application Architecture Artifacts](https://arc.fuet.ch/concepts/enterprise-architecture/application-architecture-artifacts.md)
- The diagram shows dependencies between applications, not only a list of applications. → [Application Interface Diagram](https://arc.fuet.ch/concepts/enterprise-architecture/application-interface-diagram.md)
- Capabilities describe what the business does, and process steps are kept in separate process models. → [Capability identification and naming](https://arc.fuet.ch/concepts/enterprise-architecture/capability-identification-and-naming.md)
- Capability descriptions state what the business must be able to do and do not describe tasks, sequence, or systems. → [Capability versus process](https://arc.fuet.ch/concepts/enterprise-architecture/capability-versus-process.md)
- The data inventory is kept as a catalog in the Architecture Repository. → [Data Architecture Artifact](https://arc.fuet.ch/concepts/enterprise-architecture/data-architecture-artifacts.md)
- Each entity names exactly one system of record. → [Data Entity/Data Component Catalog](https://arc.fuet.ch/concepts/enterprise-architecture/data-entity-data-component-catalog.md)
- Cross-layer relationships (use/serving and realization) are shown, not just isolated layers. → [Enterprise Architecture Layers](https://arc.fuet.ch/concepts/enterprise-architecture/enterprise-architecture-structure-business-and-it-architecture.md)
- The document states a target application architecture that enables the business architecture and the architecture vision. → [TOGAF Phase C: Application Architecture](https://arc.fuet.ch/concepts/enterprise-architecture/togaf-phase-c-application-architecture.md)
- Story benefits state business impact and are not written as formal postconditions. → [Consistency of User Story and Use Case](https://arc.fuet.ch/concepts/functional-requirements/consistency-of-user-story-and-use-case.md)
- Use cases are annotated with a goal level so readers know the expected level of detail. → [Goal Hierarchy to Component Mapping](https://arc.fuet.ch/concepts/functional-requirements/goal-hierarchy-to-component-mapping.md)
- Blocks that group similar business functions are formed with cohesion as the primary driver. → [Goal Hierarchy to Component Mapping](https://arc.fuet.ch/concepts/functional-requirements/goal-hierarchy-to-component-mapping.md)
- The decomposition is justified by quality attribute requirements, not only by the list of functions. → [Responsibility Allocation](https://arc.fuet.ch/concepts/functional-requirements/responsibility-allocation.md)
- The deployment or operational description shows only the infrastructure needed to place the building blocks. → [Architect's Four Key Work Products](https://arc.fuet.ch/concepts/fundamentals/architect-s-four-key-work-products.md)
- Layers are defined as package patterns, and the allowed interactions between them are stated. → [Architecturally Evident Coding Style](https://arc.fuet.ch/concepts/fundamentals/architecturally-evident-coding-style.md)
- Naming conventions, such as the name pattern for methods that return collections, are checked automatically. → [Architecturally Evident Coding Style](https://arc.fuet.ch/concepts/fundamentals/architecturally-evident-coding-style.md)
- Each deeper level of the building block view zooms into selected blocks of the level above. → [Architecture Level](https://arc.fuet.ch/concepts/fundamentals/architecture-levels.md)
- The hierarchy continues to further levels only where details of a block need describing. → [Architecture Level](https://arc.fuet.ch/concepts/fundamentals/architecture-levels.md)
- Blocks chosen for a lower-level description are important, risky, complex or volatile; other blocks are not forced to have one. → [Architecture Level](https://arc.fuet.ch/concepts/fundamentals/architecture-levels.md)
- Each channel is documented as point-to-point (one receiver per message) or publish-subscribe (a copy to every subscriber). → [Connector Cardinality](https://arc.fuet.ch/concepts/fundamentals/connector-cardinality.md)
- For publish-subscribe channels, the subscribers are listed, since each one receives a copy. → [Connector Cardinality](https://arc.fuet.ch/concepts/fundamentals/connector-cardinality.md)
- Synchronous remote calls have timeouts, so a slow service cannot block all threads of its caller. → [Connectors and Distribution](https://arc.fuet.ch/concepts/fundamentals/connectors-and-distribution.md)
- The document records known gaps between intended and implemented architecture as risks or technical debt. → [Implicit Architecture](https://arc.fuet.ch/concepts/fundamentals/architecture-facts-and-challenges.md)
- The document names the main building blocks, their interfaces and relationships. → [Software Architecture](https://arc.fuet.ch/concepts/fundamentals/software-architecture.md)
- The system is explicitly demarcated from its environment. → [Software Architecture Basic Concepts](https://arc.fuet.ch/concepts/fundamentals/software-architecture-basic-concepts.md)
- Interactions between components are shown as explicit connectors in the architecture description. → [Software Connector](https://arc.fuet.ch/concepts/fundamentals/software-connector.md)
- Each connector plugs into identified ports of the components it joins. → [Software Connector](https://arc.fuet.ch/concepts/fundamentals/software-connector.md)
- Disordered parts of the system are identified and isolated from the rest of it. → [Sweeping It Under the Rug](https://arc.fuet.ch/concepts/fundamentals/sweeping-it-under-the-rug.md)
- Global data is split into distinct data structures. → [Sweeping It Under the Rug](https://arc.fuet.ch/concepts/fundamentals/sweeping-it-under-the-rug.md)
- The document names who owns the payload lifecycle and aligns message expiry with payload retention. → [Claim Check](https://arc.fuet.ch/concepts/integration/claim-check.md)
- The document states the completeness condition that tells the Aggregator when to publish the combined result. → [Composed Message Processor](https://arc.fuet.ch/concepts/integration/composite-message-processor.md)
- Each message channel or topic has a documented purpose, because the channel name is the assumption sender and receiver share. → [Connector Transparency (Direct vs Indirect Connection)](https://arc.fuet.ch/concepts/integration/connector-transparency.md)
- Where a receiver needs data the sender does not hold, the document names an enrichment step that supplies it. → [Content Enricher and Content Filter](https://arc.fuet.ch/concepts/integration/content-enricher.md)
- Where a consumer needs only a few items from a large message, the document names a Content Filter that removes the other items. → [Content Filter](https://arc.fuet.ch/concepts/integration/content-filter.md)
- The routing rules are documented and kept easy to maintain. → [Content-based Router](https://arc.fuet.ch/concepts/integration/content-based-router.md)
- Each data type that the system sends has its own channel, so all messages on one channel share one type. → [Datatype Channel](https://arc.fuet.ch/concepts/integration/datatype-channel.md)
- The document states whether the design uses a control channel for recipients to register and unsubscribe. → [Dynamic Router](https://arc.fuet.ch/concepts/integration/dynamic-router.md)
- Channels where each message must reach only one receiver are identified as point-to-point. → [Enterprise Integration Patterns](https://arc.fuet.ch/concepts/integration/messaging-pattern-language.md)
- The document states where the envelope is removed, so the receiving application gets the original data. → [Envelope Wrapper](https://arc.fuet.ch/concepts/integration/envelope-wrapper.md)
- Consumers are described as idempotent, because delivery is typically at-least-once. → [Event Sourcing with Distributed Event Log](https://arc.fuet.ch/concepts/integration/event-sourcing-with-distributed-event-log.md)
- The document states how a burst of messages is handled, for example through a buffering queue, autoscaling or several competing consumers. → [Event-Driven Consumer](https://arc.fuet.ch/concepts/integration/event-driven-consumer.md)
- The document says how often each file is produced and why that interval fits the business. → [File Transfer](https://arc.fuet.ch/concepts/integration/file-transfer.md)
- A router or other mechanism that reads the format identifier and sends messages to the right recipient is described. → [Format Indicator](https://arc.fuet.ch/concepts/integration/format-identifier.md)
- Where a legacy or external system is integrated, the document says how its semantics are kept out of the new design, for example with an anti-corruption layer. → [Integration](https://arc.fuet.ch/concepts/integration/integration.md)
- Where File Transfer is used, the file name, location and format are agreed and documented. → [Integration Styles](https://arc.fuet.ch/concepts/integration/integration-styles-overview.md)
- The document states whether each channel is Point-to-Point (one receiver per message) or Publish-Subscribe (a copy per subscriber). → [Message Channel](https://arc.fuet.ch/concepts/integration/message-channel.md)
- Each filter in the design states the content criteria that decide whether a message passes. → [Message Filter](https://arc.fuet.ch/concepts/integration/message-filter.md)
- Where a message must reach a different system depending on its content, a Content-Based Router is used instead of the sender choosing the target. → [Message Routing](https://arc.fuet.ch/concepts/integration/message-routing.md)
- The document names the message size limit that makes splitting necessary. → [Message Sequence](https://arc.fuet.ch/concepts/integration/message-sequence.md)
- The document states where an expiration time applies and that consumers ignore expired messages. → [Message Structure](https://arc.fuet.ch/concepts/integration/message-structure.md)
- Where applications use different data formats, the document names a translator step between them. → [Message Translator](https://arc.fuet.ch/concepts/integration/message-translator.md)
- The document states the delivery guarantee in use and whether messages are persisted until acknowledged. → [Messaging](https://arc.fuet.ch/concepts/integration/messaging.md)
- The document names the formats that arrive and states which translator handles each one. → [Normalizer](https://arc.fuet.ch/concepts/integration/normalizer.md)
- The document states which channels must deliver each message to exactly one receiver, and uses point-to-point channels for them. → [Point-to-Point Channel](https://arc.fuet.ch/concepts/integration/point-to-point-channel.md)
- The document states whether each consumer pulls messages (polling) or is handed them (event-driven). → [Polling Consumer](https://arc.fuet.ch/concepts/integration/polling-consumer.md)
- The document states why a fixed sequence of steps does not work before it introduces a Process Manager. → [Process Manager](https://arc.fuet.ch/concepts/integration/process-manager.md)
- The document explains how subscribers handle duplicate messages, for example by being idempotent. → [Publish/Subscribe Channel](https://arc.fuet.ch/concepts/integration/publish-subscribe-channel.md)
- Where one message must reach a dynamically chosen set of receivers, the document names Recipient List as the routing approach. → [Recipient List](https://arc.fuet.ch/concepts/integration/recipient-list.md)
- Remote interfaces are coarse-grained rather than a direct copy of in-process method calls. → [Remote Procedure Call](https://arc.fuet.ch/concepts/integration/remote-procedure-call.md)
- Messages that need varying sequences of steps carry a slip listing those steps, rather than relying on a fixed pipeline. → [Routing Slip](https://arc.fuet.ch/concepts/integration/routing-slip.md)
- The document states how long the aggregator waits for replies, such as a timeout, and what happens when it expires. → [Scatter/Gather](https://arc.fuet.ch/concepts/integration/scatter-gather.md)
- The selection criteria of all consumers on a channel together cover every valid selection value. → [Selective Consumer](https://arc.fuet.ch/concepts/integration/selective-consumer.md)
- Ownership and agreement of the shared schema across teams or departments is addressed. → [Shared Database](https://arc.fuet.ch/concepts/integration/shared-database.md)
- For each synchronous call, the document says what happens when the callee is unavailable. → [Software Connector Classification](https://arc.fuet.ch/concepts/integration/classification-of-integration-patterns.md)
- The document states how each pipe connects filters and which output feeds which input. → [Stream Connector](https://arc.fuet.ch/concepts/integration/stream.md)
- Synchronous remote calls have timeouts and, where useful, retries or a circuit breaker. → [Synchronous vs Asynchronous Connector](https://arc.fuet.ch/concepts/integration/synchronous-vs-asynchronous-connector.md)
- Text annotations are linked to the element they comment on by a dotted association. → [BPMN Artifacts (Group and Text Annotation)](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-artifacts-group-and-text-annotation.md)
- Message flow is used only between different pools, never between elements inside one pool. → [BPMN Core Elements](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-element-categories.md)
- Pools represent participants such as different organizations, and lanes divide work inside a pool by role or function. → [BPMN Core Elements](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-element-categories.md)
- Messages that cross organizational boundaries are drawn as message flows between pools, not inside one pool. → [BPMN Focus on Connected Businesses](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-focus-on-connected-businesses.md)
- Sequence flows do not cross each other, and very long flows are avoided or replaced by link events. → [BPMN Layout Guideline](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-layout-guideline.md)
- Communication between separate pools is shown with dashed message flows, not with sequence flow. → [BPMN Swimlane (Pool and Lane)](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-swimlane-pool-and-lane.md)
- Every lane sits inside a pool, and the diagram states what its lanes represent. → [BPMN Swimlane (Pool and Lane)](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-swimlane-pool-and-lane.md)
- Processes run by different participants are modeled in separate pools, and message flows (not links inside one pool) connect them. → [Data Exchange between BPMN Processes](https://arc.fuet.ch/concepts/modeling-bpmn/data-exchange-between-bpmn-processes.md)
- Decision tables list their inputs, outputs and rules. → [Decision Model and Notation](https://arc.fuet.ch/concepts/modeling-bpmn/decision-model-and-notation.md)
- The top-level end-to-end diagram shows all participating pools, including external parties. → [Levels of Process Modeling](https://arc.fuet.ch/concepts/modeling-bpmn/levels-of-process-modeling.md)
- Subprocess detail sits in separate child diagrams reached through collapsed subprocesses, not mixed into the parent diagram. → [Levels of Process Modeling](https://arc.fuet.ch/concepts/modeling-bpmn/levels-of-process-modeling.md)
- Every filled diamond sits at the whole (composite) end of its association. → [Aggregation vs. Composition](https://arc.fuet.ch/concepts/modeling-uml/composition-versus-aggregation.md)
- The document states whether its UML diagrams are sketches (selective communication) or complete specifications. → [Barriers to UML Adoption](https://arc.fuet.ch/concepts/modeling-uml/barriers-to-uml-adoption.md)
- If a lighter notation such as C4 is used instead of full UML, the document says so. → [Barriers to UML Adoption](https://arc.fuet.ch/concepts/modeling-uml/barriers-to-uml-adoption.md)
- No multiplicity has a lower bound greater than its upper bound. → [Common Class Diagram Modeling Mistakes](https://arc.fuet.ch/concepts/modeling-uml/common-class-diagram-modeling-mistakes.md)
- No part in a composition (filled diamond) belongs to more than one whole. → [Common Class Diagram Modeling Mistakes](https://arc.fuet.ch/concepts/modeling-uml/common-class-diagram-modeling-mistakes.md)
- Every artifact on a component diagram is linked by a manifestation relationship to the model element, such as a component, that it embodies. → [Common Component Diagram Mistake](https://arc.fuet.ch/concepts/modeling-uml/component-diagram-modeling-mistakes.md)
- The dependency graph between components has no cycles. → [Common Component Diagram Mistake](https://arc.fuet.ch/concepts/modeling-uml/component-diagram-modeling-mistakes.md)
- Where a cycle existed, it was broken, for example by moving shared dependencies into a new package. → [Common Component Diagram Mistake](https://arc.fuet.ch/concepts/modeling-uml/component-diagram-modeling-mistakes.md)
- Each delegation connector runs from a port on the component boundary to an inner part that realizes the behavior. → [Component Connector (Assembly and Delegation)](https://arc.fuet.ch/concepts/modeling-uml/component-connector-assembly-and-delegation.md)
- Each assembly connector joins a part that provides a service to a part that uses it. → [Component Connector (Assembly and Delegation)](https://arc.fuet.ch/concepts/modeling-uml/component-connector-assembly-and-delegation.md)
- The elements at both ends of every connector have compatible interface features. → [Component Connector (Assembly and Delegation)](https://arc.fuet.ch/concepts/modeling-uml/component-connector-assembly-and-delegation.md)
- Each delegation connector joins a boundary port or interface to an internal one of the same kind. → [Delegation Connector](https://arc.fuet.ch/concepts/modeling-uml/delegation-connector.md)
- Connectors between sibling components are drawn as assembly connectors, and delegation is used only for crossing a component boundary. → [Delegation Connector](https://arc.fuet.ch/concepts/modeling-uml/delegation-connector.md)
- A whitebox shows the building blocks inside a blackbox and their relationships. → [Delegation Connector](https://arc.fuet.ch/concepts/modeling-uml/delegation-connector.md)
- Every piece of source code has a place in the building block view. → [Differences between Class, Component and Package Diagrams](https://arc.fuet.ch/concepts/modeling-uml/class-component-and-package-diagram-differences.md)
- The building block view is hierarchical: level 1 is the whitebox of the overall system, and lower levels zoom into selected blocks. → [Differences between Class, Component and Package Diagrams](https://arc.fuet.ch/concepts/modeling-uml/class-component-and-package-diagram-differences.md)
- Where a hierarchy is drawn with components or packages, the diagram nests them. → [Differences between Class, Component and Package Diagrams](https://arc.fuet.ch/concepts/modeling-uml/class-component-and-package-diagram-differences.md)
- Object diagrams model each object and link as an instance specification. → [Instance Specification](https://arc.fuet.ch/concepts/modeling-uml/instance-specification.md)
- Slots show feature values as a feature name, an equal sign and a value. → [Instance Specification](https://arc.fuet.ch/concepts/modeling-uml/instance-specification.md)
- Static structure is shown in the building block view, separate from runtime behavior. → [Matching Diagram Type to System Aspect](https://arc.fuet.ch/concepts/modeling-uml/matching-diagram-type-to-system-aspect.md)
- The documentation states whether diagrams come from a central model or from independent drawings. → [Modeling Tool vs. Drawing Tool](https://arc.fuet.ch/concepts/modeling-uml/modeling-tool-vs-drawing-tool.md)
- If a modeling tool is used, it is limited to the graphical part of the documentation. → [Modeling Tool vs. Drawing Tool](https://arc.fuet.ch/concepts/modeling-uml/modeling-tool-vs-drawing-tool.md)
- The top-level building block view shows the whole system as a white box with all top-level blocks as black boxes. → [Nested Components and Subsystems](https://arc.fuet.ch/concepts/modeling-uml/nested-components-and-subsystems.md)
- Selected blocks are refined in further levels, and each level is documented in its matching section 5-n. → [Nested Components and Subsystems](https://arc.fuet.ch/concepts/modeling-uml/nested-components-and-subsystems.md)
- Ports on a nested component's boundary are shown, and delegation to internal parts is clear. → [Nested Components and Subsystems](https://arc.fuet.ch/concepts/modeling-uml/nested-components-and-subsystems.md)
- Element names are unique within each package of the diagram. → [Package Diagram](https://arc.fuet.ch/concepts/modeling-uml/package-diagram.md)
- Package dependencies without a label are intended to be read as package imports. → [Package Diagram](https://arc.fuet.ch/concepts/modeling-uml/package-diagram.md)
- If packages represent layers, the diagram shows the layered architecture. → [Package Diagram](https://arc.fuet.ch/concepts/modeling-uml/package-diagram.md)
- The package dependencies contain no cycles and can be drawn as a directed acyclic graph. → [Package Diagram Modeling Mistake](https://arc.fuet.ch/concepts/modeling-uml/package-diagram-modeling-mistakes.md)
- Every relationship between packages carries a keyword such as import or access, so the meaning is clear. → [Package Diagram Modeling Mistake](https://arc.fuet.ch/concepts/modeling-uml/package-diagram-modeling-mistakes.md)
- Containment goes from package to members: packages contain classes or other packages, never the reverse. → [Package Diagram Modeling Mistake](https://arc.fuet.ch/concepts/modeling-uml/package-diagram-modeling-mistakes.md)
- Every dependency between packages carries an explicit label for its relationship type. → [Package Relationships (Import, Access, Merge, Use)](https://arc.fuet.ch/concepts/modeling-uml/package-relationships-import-access-merge-use.md)
- Each merge connects two packages and its intent (combining their contents) is clear to the reader. → [Package Relationships (Import, Access, Merge, Use)](https://arc.fuet.ch/concepts/modeling-uml/package-relationships-import-access-merge-use.md)
- Where imported elements and a merge interact, the document states what is intended. → [Package Relationships (Import, Access, Merge, Use)](https://arc.fuet.ch/concepts/modeling-uml/package-relationships-import-access-merge-use.md)
- Ports that the environment can see are drawn straddling the boundary of their owner. → [Port](https://arc.fuet.ch/concepts/modeling-uml/component-port.md)
- Each port shows which interfaces the owner provides and which it requires through that port. → [Port](https://arc.fuet.ch/concepts/modeling-uml/component-port.md)
- Any behavior port belongs to an owner that has a defined behavior, so requests are not lost. → [Port](https://arc.fuet.ch/concepts/modeling-uml/component-port.md)
- Provided interfaces are drawn as balls that name the services, data, or events a building block offers. → [Provided and Required Interface](https://arc.fuet.ch/concepts/modeling-uml/provided-and-required-interface.md)
- Ball and socket notation is combined with port symbols where a component has several interfaces. → [Provided and Required Interface](https://arc.fuet.ch/concepts/modeling-uml/provided-and-required-interface.md)
- Each region has an initial pseudostate with a single transition to the default state. → [State Machine Diagram Modeling Mistakes](https://arc.fuet.ch/concepts/modeling-uml/state-machine-diagram-modeling-mistakes.md)
- Each transition that must not always fire has a guard, and the guard is a yes/no check. → [State Machine Transition](https://arc.fuet.ch/concepts/modeling-uml/state-machine-transition.md)
- Each template binding is drawn as a dashed arrow from the bound element to the template, with the «bind» keyword. → [Transfer Object Pattern as Package Template](https://arc.fuet.ch/concepts/modeling-uml/transfer-object-pattern-as-package-template.md)
- Transfer Objects appear only where calls cross process boundaries and are expensive; local designs use domain objects directly. → [Transfer Object Pattern as Package Template](https://arc.fuet.ch/concepts/modeling-uml/transfer-object-pattern-as-package-template.md)
- Each diagram in the architecture document is identified as a structure diagram or a behavior diagram. → [UML 2.5 Diagram Taxonomy](https://arc.fuet.ch/concepts/modeling-uml/uml-diagram-taxonomy.md)
- Each relationship between two classes is shown either as an association line or as an attribute, not both. → [UML Association](https://arc.fuet.ch/concepts/modeling-uml/association.md)
- Role names on association ends match the attribute names used in code. → [UML Association](https://arc.fuet.ch/concepts/modeling-uml/association.md)
- The class diagram shows only the interesting classes, not every class in the system. → [UML Class Diagram](https://arc.fuet.ch/concepts/modeling-uml/class-diagram.md)
- Dependency lines are not drawn in addition to associations or generalizations between the same classes. → [UML Class Diagram](https://arc.fuet.ch/concepts/modeling-uml/class-diagram.md)
- The ball-and-socket notation is not used to link interfaces in class diagrams. → [UML Class Diagram](https://arc.fuet.ch/concepts/modeling-uml/class-diagram.md)
- Associations are used for field-like structural links between classes. → [UML Class Diagram Relationship](https://arc.fuet.ch/concepts/modeling-uml/class-diagram-relationships.md)
- Any aggregation (white diamond) in the diagram comes with an explanation of what it means. → [UML Class Diagram Relationship](https://arc.fuet.ch/concepts/modeling-uml/class-diagram-relationships.md)
- Each component's required interfaces are satisfied by a provided interface of another component, shown by a dependency or ball-and-socket. → [UML Component Diagram](https://arc.fuet.ch/concepts/modeling-uml/uml-component-diagram.md)
- Interfaces are attached to components through ports, and each port has an interface as its type. → [UML Component Diagram](https://arc.fuet.ch/concepts/modeling-uml/uml-component-diagram.md)
- Where a component has nested parts, delegations link its outer ports to inner parts. → [UML Component Diagram](https://arc.fuet.ch/concepts/modeling-uml/uml-component-diagram.md)
- Generalization arrows use a hollow triangle and point to the more general class. → [UML Generalization and Specialization](https://arc.fuet.ch/concepts/modeling-uml/generalization-and-specialization.md)
- Black-box building blocks describe their responsibility and their interfaces, not their internals. → [UML Interface](https://arc.fuet.ch/concepts/modeling-uml/uml-interface.md)
- Every diagram has a legend that explains any notation that is not standard. → [UML Modeling Anti-Pattern](https://arc.fuet.ch/concepts/modeling-uml/uml-modeling-anti-patterns.md)
- The document states which modeling standards the team follows. → [UML Modeling Best Practice](https://arc.fuet.ch/concepts/modeling-uml/uml-modeling-best-practice.md)
- The document makes clear whether diagrams are sketches or more precise specifications. → [UML Modeling Best Practice](https://arc.fuet.ch/concepts/modeling-uml/uml-modeling-best-practice.md)
- Each diagram states whether it shows the domain, the software specification, or the implementation. → [UML Perspectives: Conceptual, Specification, Implementation](https://arc.fuet.ch/concepts/modeling-uml/uml-views-conceptual-specification-implementation.md)
- The building block view shows the static decomposition of the system, starting with a level 1 white box containing black boxes. → [UML Structure Diagram](https://arc.fuet.ch/concepts/modeling-uml/structure-diagram.md)
- The deployment view maps software to hardware, with a UML deployment diagram and nested diagrams for complex infrastructure. → [UML Structure Diagram](https://arc.fuet.ch/concepts/modeling-uml/structure-diagram.md)
- The document states which development method the UML diagrams are used with, because UML itself is not a method. → [Unified Modeling Language (UML)](https://arc.fuet.ch/concepts/modeling-uml/uml-unified-modeling-language.md)
- The documentation states which notation its diagrams use, and stakeholders have a shared understanding of it. → [Why Use UML in Architecture Documentation](https://arc.fuet.ch/concepts/modeling-uml/why-use-uml-in-architecture-documentation.md)
- Speculative features or abstractions that make current requirements harder to understand are absent or justified. → [Complexity Reduction](https://arc.fuet.ch/concepts/principles/complexity-reduction.md)
- Dependencies point toward abstractions, not concrete implementations. → [Component Design Principles](https://arc.fuet.ch/concepts/principles/component-design-principles.md)
- Shared data formats and message-order assumptions are documented as dependencies, even where the systems look decoupled. → [Connect or Disconnect](https://arc.fuet.ch/concepts/principles/connect-or-disconnect.md)
- Modules are described by one well-defined task each, rather than grouped arbitrarily. → [Coupling and Cohesion](https://arc.fuet.ch/concepts/principles/coupling-and-cohesion.md)
- Each building block has a responsibility that can be stated in one sentence without 'and'. → [High Cohesion](https://arc.fuet.ch/concepts/principles/high-cohesion.md)
- Each module hides one identified design decision from the other modules. → [Information Hiding](https://arc.fuet.ch/concepts/principles/information-hiding.md)
- Interfaces are defined around the needs of specific consumers, not copied from all public methods of a class. → [Interface Segregation Principle](https://arc.fuet.ch/concepts/principles/interface-segregation-principle.md)
- No single large class or interface serves many different clients with many different methods. → [Interface Segregation Principle](https://arc.fuet.ch/concepts/principles/interface-segregation-principle.md)
- Shared custom data types between components are identified, since they create hidden dependencies. → [Loose Coupling](https://arc.fuet.ch/concepts/principles/loose-coupling.md)
- The document states how instability and abstractness are computed for each component, using the same definitions throughout. → [Main Sequence (Balance of Abstractness and Instability)](https://arc.fuet.ch/concepts/principles/main-sequence.md)
- Building blocks are formed mainly by cohesion. → [Modularity](https://arc.fuet.ch/concepts/principles/modularity.md)
- Extension points exist only where change is expected, and unused extension points are removed. → [Open-Closed Principle](https://arc.fuet.ch/concepts/principles/open-closed-principle.md)
- The document states which layers may communicate with which, for example UI only with the business layer. → [Separation of Concerns](https://arc.fuet.ch/concepts/principles/separation-of-concerns.md)
- The documentation states whether traceability is full-scale or pragmatic. → [Traceability](https://arc.fuet.ch/concepts/principles/traceability.md)
- The fulfilled-requirements field of a building block is filled only where traceability is truly needed. → [Traceability](https://arc.fuet.ch/concepts/principles/traceability.md)
- For each module, the document states why its parts are grouped (for example one task, same data, or same time). → [Types of Cohesion](https://arc.fuet.ch/concepts/principles/types-of-cohesion.md)
- Classes with more than one connected group of methods (LCOM4 above one) are reviewed for splitting. → [Types of Cohesion](https://arc.fuet.ch/concepts/principles/types-of-cohesion.md)
- The document names the element types of each pattern and their responsibilities. → [Architectural Pattern](https://arc.fuet.ch/concepts/styles-patterns/architectural-pattern.md)
- The reasons for the chosen style are recorded, given that late changes are costly. → [Architectural Pattern vs. Design Pattern](https://arc.fuet.ch/concepts/styles-patterns/architectural-pattern-vs-design-pattern.md)
- Each knowledge source is described as an independent module with a specific expertise. → [Blackboard Pattern](https://arc.fuet.ch/concepts/styles-patterns/blackboard-architecture.md)
- The document explains how the broker's robustness and efficiency are ensured, since the system depends on it. → [Broker Pattern](https://arc.fuet.ch/concepts/styles-patterns/broker-pattern.md)
- Boundaries between layers are crossed with simple data structures such as DTOs. → [Clean Architecture](https://arc.fuet.ch/concepts/styles-patterns/clean-architecture.md)
- Raw batch-layer data is described as immutable and append-only, so views can be recomputed. → [Lambda Architecture](https://arc.fuet.ch/concepts/styles-patterns/lambda-architecture.md)
- The document says whether layering is strict or relaxed, and names the latency or coupling consequences. → [Layered Architecture](https://arc.fuet.ch/concepts/styles-patterns/layered-architecture.md)
- No lower layer uses a higher layer. → [Layers Pattern](https://arc.fuet.ch/concepts/styles-patterns/layers-pattern.md)
- The building block view shows the static decomposition of the system, with level 1 as a white box of the whole system. → [Layers and Components Decomposition](https://arc.fuet.ch/concepts/styles-patterns/layers-and-components-decomposition.md)
- Layer dependencies run top to bottom, and the document says layers are logical, not physical tiers. → [Layers and Components Decomposition](https://arc.fuet.ch/concepts/styles-patterns/layers-and-components-decomposition.md)
- Blocks that are not detailed are shown as black boxes with their inner workings hidden. → [Layers and Components Decomposition](https://arc.fuet.ch/concepts/styles-patterns/layers-and-components-decomposition.md)
- The document accounts for the performance cost of message exchange between clients and service providers. → [Microkernel Pattern](https://arc.fuet.ch/concepts/styles-patterns/microkernel-pattern.md)
- Each service owns its data and schema, with no shared database. → [Microservices Architecture](https://arc.fuet.ch/concepts/styles-patterns/microservices-architecture.md)
- Controllers and views have distinct, independent input and output responsibilities. → [Model-View-Controller Pattern](https://arc.fuet.ch/concepts/styles-patterns/model-view-controller-pattern.md)
- The input and output schema of every filter is documented, and each filter's input matches the previous filter's output. → [Pipe-and-Filter](https://arc.fuet.ch/concepts/styles-patterns/pipe-and-filter-pattern.md)
- Pipes contain no routing or business logic; all logic sits in filters. → [Pipes and Filters](https://arc.fuet.ch/concepts/styles-patterns/pipes-and-filters.md)
- The document names the broker or event bus that sits between publishers and subscribers. → [Publish-Subscribe Pattern](https://arc.fuet.ch/concepts/styles-patterns/publish-subscribe-pattern.md)
- Each service has a description with the information needed to use it. → [Service-Oriented Architecture](https://arc.fuet.ch/concepts/styles-patterns/service-oriented-architecture.md)
- Where hot spares are used, the document explains how failures are detected, for example by voting. → [Active Redundancy](https://arc.fuet.ch/concepts/tactics/active-redundancy.md)
- The document names which component sends the heartbeat and which component listens for it. → [Heartbeat](https://arc.fuet.ch/concepts/tactics/heartbeat.md)
- The document states which modifiability tactic group (cohesion, coupling, binding time) each tactic belongs to. → [Increase Cohesion](https://arc.fuet.ch/concepts/tactics/increase-cohesion.md)
- The document states which distribution algorithm the balancer uses, such as round-robin, least connections or weighted. → [Load Balancer](https://arc.fuet.ch/concepts/tactics/load-balancer.md)
- Event senders publish to a channel and do not need to know their subscribers. → [Modifiability Tactics in SOA](https://arc.fuet.ch/concepts/tactics/modifiability-tactics-in-soa.md)
- Similar dependencies on a common service are hidden behind one shared contract. → [Reduce Coupling](https://arc.fuet.ch/concepts/tactics/reduce-coupling.md)
- Cohesive code that changes as one unit has not been split. → [Split Module](https://arc.fuet.ch/concepts/tactics/split-module.md)
- The top-level decomposition names the pattern used, if any. → [System Idea](https://arc.fuet.ch/concepts/vision-stakeholders/system-idea.md)