arc42 section 5: Building Block View

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