Glossary
This glossary gives quick definitions for terms used across the handbook.
Terms
| Term | Definition | Related Sections |
|---|---|---|
| Abstraction | A design move that exposes only the behavior needed by a client and hides internal mechanics. | Abstraction and Boundaries, Class Design |
| Acceptance Criteria | Explicit behavior statements that define when a feature is complete. | Correctness and Testing |
| Adapter | An outer layer component that translates between a core contract and a concrete technology. | Adapter Pattern, Onion Architecture, Hexagonal Architecture |
| ACID Transaction | A transaction model with atomicity, consistency, isolation, and durability guarantees for one commit boundary. | The Database Dilemma |
| API Adapter | A boundary component that receives external requests and forwards use case calls to inner layers. | Onion Architecture, Hexagonal Architecture |
| Application Service | A use case coordinator that invokes domain behavior and boundary ports. | Onion Architecture |
| Anti-Corruption Layer | A translation boundary that isolates one domain model from external model semantics and protocol details. | Microservices Architectural Style, Onion Architecture, Hexagonal Architecture |
| Assertion | A test statement that verifies one expected behavior result. | The Multiple Assert Problem, Correctness and Testing |
| Architecture Test | An automated test that checks structural rules such as dependency direction across layers. | Onion Architecture |
| Back-Pressure | A control mechanism that limits intake rate when downstream processing capacity is saturated. | Message-Driven Architecture, Service Interaction Style Selection Framework |
| Behavior Equivalence Test | A verification that checks equivalent domain outcomes across different transport channels for the same capability. | Hexagonal with REST and gRPC in Microservices, Correctness and Testing |
| Blast Radius | The scope of files, modules, and behaviors affected by one change. | Simplicity First |
| Bounded Context | A domain boundary where terms and rules keep one consistent meaning. | Onion Architecture |
| Behavioral Subtyping | A contract rule where each subtype preserves the required behavior of its base abstraction. | Liskov Substitution Principle, Dependency Inversion |
| Boundary | The explicit edge where ownership, contracts, and visibility rules apply. | Abstraction and Boundaries, Class Design |
| CAP Theorem | A distributed systems model that frames tradeoffs between consistency, availability, and partition tolerance. | The Database Dilemma |
| Canonical Data Owner | The single source that owns writes and authoritative meaning for one domain concept. | State and Data Modeling |
| Change Coupling | A measured relation where two modules or services change together across commits, indicating hidden dependency pressure. | Microservices Architectural Style, Modularity and Composition |
| Call Chain | A sequence of chained method calls that traverses nested objects. | Demeter's Law, Class Design |
| Circuit Breaker | A fault control pattern that stops repeated failing remote calls for a cooldown interval. | Resilience and Recovery |
| Capability Profile | A structured description of a capability using latency, consistency, consumer, and evolution characteristics for architecture decisions. | Service Interaction Style Selection Framework |
| Class Boundary | The scope of state and behavior a class owns and protects. | Class Design |
| Compile-Time Dependency | A dependency visible in imports or type references during build time. | Onion Architecture |
| Computation Function | A function focused on deterministic data work such as validation, mapping, filtering, or calculation. | Single Responsibility Principle |
| Composition | A design style that combines focused units into a larger behavior flow. | Modularity and Composition |
| Composition Root | A single assembly point where concrete dependencies are created and wired to abstractions. | Dependency Injection |
| Concentric Rings | The layered onion structure where core rules stay at the center and infrastructure stays outside. | Onion Architecture |
| Contract | A stable interface agreement for behavior, data shape, and error expectations. | Abstraction and Boundaries, Onion Architecture |
| Contract Drift | Progressive divergence in semantics or behavior between consumers and providers that share nominally the same interface. | Service Contracts with REST, Service Contracts with gRPC |
| Consumer-Driven Contract Test | A compatibility test where consumer expectations are validated against provider behavior before deployment. | Correctness and Testing, Service Contracts with gRPC |
| Correlation ID | A unique transaction identifier assigned at request ingress and propagated across components so logs and traces can be joined end to end. | Correlation IDs, Observability in Microservices, Resilience and Recovery |
| Coupling | The degree of interdependence between modules, classes, or services. | Abstraction and Boundaries, Modularity and Composition |
| Coordinator Function | A function that controls sequence and delegates work to focused collaborators. | Single Responsibility Principle |
| CQRS | Command Query Responsibility Segregation, a model that separates write operations from read operations. | Onion Architecture |
| Cognitive Load | The mental effort required for a team to understand, operate, and change a service safely. | Microservices Architectural Style, Modern Monolith Architecture |
| Consistency Model | The read visibility guarantees that define when writes become observable across nodes. | The Database Dilemma |
| Context Map | A strategic domain model that documents how bounded contexts relate through dependency and integration patterns. | Microservices Architectural Style, Onion Architecture |
| Conway's Law | An observation that system structure mirrors communication structure across teams that build it. | Microservices Architectural Style, Modern Monolith Architecture |
| Data Model | A formal representation of system state, constraints, and relationships. | State and Data Modeling |
| Data Shape Adaptation | A mapping process that converts external payload fields and types into a canonical internal schema used by the system. | Adapter Pattern, State and Data Modeling |
| Decoupling | A design result where two parts can change with low direct impact on each other. | Abstraction and Boundaries |
| Demeter's Law | A rule that limits method calls to direct collaborators and avoids deep navigation chains. | Demeter's Law, Abstraction and Boundaries, Modularity and Composition, Simplicity First, Correctness and Testing, Class Design |
| Direct Collaborator | An object that is an immediate field, parameter, or local instance available to a method. | Demeter's Law |
| Dependency Direction | The structural direction in which compile time references are allowed to point. | Onion Architecture |
| Dependency Injection | A pattern where an object receives collaborators from the outside instead of creating them internally. | Dependency Injection, Abstraction and Boundaries, Modularity and Composition, Simplicity First, Correctness and Testing |
| Dependency Inversion Principle | A rule that states high-level policy should depend on abstractions, not concrete details. | Dependency Inversion, Abstraction and Boundaries, Modularity and Composition, Simplicity First, Correctness and Testing, Onion Architecture |
| Deterministic Test | A test that returns the same result under the same input and environment conditions. | Correctness and Testing |
| Disaster Recovery | Planned restoration steps that return service after major outages. | Resilience and Recovery |
| Device Posture | The current security state of a device, including compliance signals used in runtime access decisions. | Zero Trust Architecture |
| Distributed Transaction | A transaction coordination model that spans multiple services or resources across network boundaries. | Event-Driven Messaging, The Database Dilemma |
| Distributed System | A system with multiple networked nodes that coordinate state and behavior. | Resilience and Recovery, Onion Architecture |
| Domain Model | The central representation of business concepts, rules, and invariants. | Onion Architecture, Class Design |
| Domain Service | A domain layer operation that captures business logic not owned by one entity. | Onion Architecture |
| Driven Port | A port called by core logic to reach external capabilities such as persistence or messaging. | Hexagonal Architecture, Onion Architecture |
| Driving Port | A port used by inbound adapters to invoke core use cases. | Hexagonal Architecture |
| Durability Requirement | A decision criterion that states whether operation results must survive process restart and infrastructure failure. | The Database Dilemma |
| East-West Traffic | Internal service-to-service traffic inside a platform or microservice environment. | Hexagonal with REST and gRPC in Microservices, gRPC Constraints and Goals |
| Error Budget | The allowed reliability loss that balances delivery speed and operational stability. | Resilience and Recovery |
| Event Contract | A published message schema and semantic agreement that defines event name, version, fields, and processing meaning. | Event-Driven Messaging |
| Event Storming | A collaborative modeling workshop that maps domain events, commands, policies, and invariants to discover domain boundaries. | Microservices Architectural Style, Onion Architecture |
| Event-Driven Messaging | A service interaction style where producers publish events and consumers react through asynchronous contracts. | Event-Driven Messaging |
| Event History | An ordered record of state transitions across time. | State and Data Modeling |
| Eventual Consistency | A consistency model where replicas converge over time and immediate read-after-write visibility is not guaranteed. | The Database Dilemma |
| Field Projection | A query operation that returns only selected fields from each record. | Landing Page |
| Failure Domain | A bounded part of a system where one fault can produce correlated impact. | Resilience and Recovery, Service Interaction Style Selection Framework |
| Fitness Function | An automated architecture check that validates structural rules such as dependency direction, contract compatibility, or latency budgets. | Microservices Architectural Style, Onion Architecture |
| Functional Test | A black-box test that validates externally visible behavior against business expectations across complete scenarios. | Integration and Functional Testing, Correctness |
| Flaky Test | A test that passes and fails without code change, often from timing or environment instability. | Correctness and Testing |
| GraphQL | A typed API style where clients request precise fields through schema-validated operations. | GraphQL Constraints and Goals, Service Contracts with GraphQL |
| GraphQL Introspection | A schema discovery capability that exposes types, fields, arguments, and deprecation metadata for tooling and runtime validation. | Service Contracts with GraphQL, GraphQL Constraints and Goals |
| GraphQL Resolver | A server function that executes one field by mapping schema requests to domain or data operations. | GraphQL Constraints and Goals, Service Contracts with GraphQL |
| GraphQL Schema | The contract definition that declares types, operations, and field semantics in a GraphQL service. | GraphQL Constraints and Goals, Service Contracts with GraphQL |
| gRPC | A high-performance RPC framework that uses Protocol Buffers contracts and HTTP/2 transport for service-to-service communication. | gRPC Constraints and Goals, Service Contracts with gRPC |
| Graceful Degradation | A resilience strategy where non-critical capabilities are reduced to preserve critical service behavior during faults. | Resilience and Recovery, Service Interaction Style Selection Framework |
| Hexagonal Architecture | A ports and adapters model that keeps core behavior independent from external technologies. | Hexagonal Architecture, Onion and Hexagonal Together |
| Hypothetical Scenario | The shared car intelligence and marketplace domain used across code samples and concept diagrams to keep examples coherent and realistic for learning. | Hypothetical Scenario |
| Infrastructure Adapter | A component in an outer ring that binds ports to concrete tools such as databases or message brokers. | Onion Architecture, Hexagonal Architecture |
| Idempotent Consumer | A message handler that produces the same durable outcome when the same event is processed more than once. | Event-Driven Messaging, Correctness and Testing |
| Integration Test | A test that verifies behavior across component or boundary interactions. | Integration and Functional Testing, Correctness |
| Interaction Style | A communication model used between software components, such as REST, GraphQL, gRPC, event channels, or message queues. | Service Interaction Style Selection Framework, Introduction to Services |
| Interface | The callable surface that represents a contract between two parts of a system. | Abstraction and Boundaries, Class Design |
| Just-in-Time Access | A security model that grants elevated permission for a short approved interval and removes it after task completion. | Zero Trust Architecture, Resilience and Recovery |
| Interface Segregation Principle | A rule that each client should depend on a narrow role interface that contains only required behavior. | Interface Segregation Principle, Dependency Inversion, Onion Architecture |
| Invariant | A condition that must stay true for valid system state. | Class Design, State and Data Modeling |
| Inversion of Control | A structural idea where object behavior is driven by external collaborators, configuration, or framework callbacks. | Dependency Inversion, Dependency Injection, Abstraction and Boundaries, Modularity and Composition |
| Latency | The elapsed time between request start and response completion. | Measurement and Performance |
| Least Privilege Access | An authorization principle where actors receive only the minimum scope required for the current action. | Zero Trust Architecture, Abstraction and Boundaries |
| Least Knowledge Principle | A design principle that keeps each unit aware of only direct collaborators and stable contracts. | Demeter's Law, Class Design |
| Little's Law | A queueing relationship where average in-system work equals arrival rate multiplied by average time in system. | Measurement and Performance |
| Liskov Substitution Principle | A rule that any implementation of an abstraction must preserve that abstraction contract in client use. | Liskov Substitution Principle, Dependency Inversion |
| Log | A timestamped event record emitted by software components for diagnostics, audit, and operational analysis. | Logs vs Metrics vs Traces, Correlation IDs |
| Message Passing | Interaction by sending method calls or commands through explicit contracts. | Class Design, Abstraction and Boundaries |
| Message-Driven Architecture | A service interaction style where one service sends command-style messages that request work execution by consumers. | Message-Driven Architecture, Event-Driven Messaging |
| Metric | A numeric time-series signal that summarizes system behavior over intervals for health tracking and alerting. | Logs vs Metrics vs Traces, Measurement and Performance |
| Micro-Segmentation | A network and service boundary strategy that limits lateral movement through small policy-controlled trust zones. | Zero Trust Architecture, Resilience and Recovery |
| Microservice | A deployable service unit with an independent domain boundary and operational lifecycle. | Onion Architecture |
| Microservices Architectural Style | A system design style where independent services align with business capabilities and own their contracts and operational lifecycle. | Microservices Architectural Style, Observability in Microservices, Service Interaction Style Selection Framework |
| Modern Monolith | One deployable application with strict internal module boundaries, explicit contracts, and architecture governance. | Modern Monolith Architecture, Microservices Architectural Style |
| MongoDB Query Document | A structured document that encodes filters and query options for MongoDB execution. | Landing Page |
| mypy | A static type checker for Python that validates type contracts such as Protocol-based structural subtyping before runtime. | Liskov Substitution with typing.Protocol and mypy, Liskov Substitution Principle |
| Multiple Assert Problem | A test design issue where one test method checks many claims and hides intent. | The Multiple Assert Problem |
| North-South Traffic | External client traffic that crosses the platform edge into service APIs. | Hexagonal with REST and gRPC in Microservices, Service Contracts with REST |
| Onion Architecture | A layered architecture model with domain code at the center and inward dependency flow. | Onion Architecture, Onion and Hexagonal Together |
| Onion and Hexagonal Composition | A combined architecture style that uses onion dependency direction with hexagonal ports and adapters. | Onion and Hexagonal Together |
| One Assert Rule | A unit test guideline that keeps one behavior claim in each test method. | The Multiple Assert Problem |
| Observer Pattern | A behavioral pattern where one subject publishes state changes to subscribed observers through a stable notification contract. | Observer Pattern, Event-Driven Messaging |
| Open-Closed Principle | A design rule where modules gain new behavior through extension points instead of edits in stable core logic. | Open-Closed Principle, Single Responsibility Principle, Dependency Inversion |
| Observability | The engineering capability to explain internal system behavior from emitted telemetry such as logs, metrics, and traces. | Correlation IDs, Logs vs Metrics vs Traces, Observability in Microservices, Measurement and Performance |
| Outbox Pattern | A reliability pattern that stores outbound messages in the same local transaction as domain state, then relays them to a broker. | Event-Driven Messaging, The Database Dilemma |
| Parent Span ID | The identifier of a span's direct parent, used to preserve causal ordering in distributed traces. | Observability in Microservices, Logs vs Metrics vs Traces |
| Pagination | A query pattern that returns data in pages across multiple requests. | Landing Page |
| Parameter Object | A pattern that groups related method inputs into one named contract object. | Parameter Object, Dependency Injection |
| Persistence-Agnostic Contract | A repository or port interface that expresses domain operations without binding method signatures to one database engine or driver API. | Repository Pattern, Dependency Inversion |
| Policy Decision Point (PDP) | The component that evaluates identity, context, resource, and policy rules to produce an access decision. | Zero Trust Architecture |
| Policy Enforcement Point (PEP) | The component that enforces policy outcomes such as allow, deny, or challenge on runtime requests. | Zero Trust Architecture, Service Contracts with REST |
| Policy Information Point (PIP) | The source of contextual attributes such as device posture, risk signals, and identity metadata for policy evaluation. | Zero Trust Architecture |
| Polyglot Persistence | An architecture strategy that uses more than one database model in one system to match operation semantics. | The Database Dilemma |
| Persisted Query | A registered GraphQL operation stored by identifier so runtime traffic can be restricted to approved query shapes. | Service Contracts with GraphQL, GraphQL Constraints and Goals |
| Percentile Latency | A latency statistic that reports the response time below which a percentage of requests complete, such as p95 or p99. | Measurement and Performance |
| Protocol Buffers | A language-neutral schema format used by gRPC to define typed messages and service methods. | gRPC Constraints and Goals, Service Contracts with gRPC |
| Role Interface | A focused interface that models one client capability boundary. | Interface Segregation Principle |
| Polymorphism | A dispatch model where client code uses a base type and runtime subtype behavior executes through that base contract. | Liskov Substitution Principle, Class Design |
| Port | An inner ring interface that declares required external behavior without concrete implementation detail. | Onion Architecture, Hexagonal Architecture |
| Protocol (Python) | A structural type contract in Python typing that defines required members without nominal inheritance. | Liskov Substitution Principle, Dependency Inversion |
| Primary Adapter | An inbound adapter that drives core behavior, such as HTTP, CLI, or job handlers. | Hexagonal Architecture |
| Post-Incident Action | A concrete corrective task created after an incident review. | Resilience and Recovery |
| Private Member | A class member accessible only inside the class implementation. | Class Design |
| Profiling | A runtime analysis practice that identifies where CPU time, memory, or contention cost accumulates during execution. | Profiling, Measurement and Performance |
| Profiler | A tool that measures where execution time and resource cost accumulate. | Profiling, Measurement and Performance |
| Property-Based Testing | A testing method that checks broad input spaces against declared invariants instead of fixed example cases only. | Correctness and Testing |
| Protected Member | A class member visible to the class and controlled subtype hierarchy. | Class Design |
| Public Interface | The exposed class surface available to client code. | Class Design |
| Query String | A URL encoded parameter string used to express filters and options for an endpoint. | Landing Page |
| Recovery | A planned return from degraded operation to normal service behavior. | Resilience and Recovery |
| Request ID | An identifier for one inbound request scope that helps correlate service logs and trace context. | Observability in Microservices, Correlation IDs |
| Reverse Conway Maneuver | A design practice where teams are reorganized to support target service boundaries and dependency direction. | Microservices Architectural Style, Modern Monolith Architecture |
| REST Constraint | A required architectural rule in REST style that shapes interaction behavior and quality characteristics. | REST Constraints and Goals |
| REST Goal | A quality objective pursued by REST constraints, such as performance, scalability, visibility, or modifiability. | REST Constraints and Goals |
| Repository | A boundary abstraction that presents persistence operations through domain friendly contracts. | Repository Pattern, Onion Architecture, Hexagonal Architecture |
| Secondary Adapter | An outbound adapter that implements driven ports for infrastructure access. | Hexagonal Architecture |
| Resilience | The ability to keep service behavior within accepted limits during faults. | Resilience and Recovery |
| REST API | A web API style that exposes resources through HTTP semantics. | Landing Page |
| Retry | A controlled repeat of a failed operation under explicit policy rules. | Resilience and Recovery |
| RPO | Recovery Point Objective, the maximum acceptable data loss window after a disruption. | Resilience and Recovery |
| RTO | Recovery Time Objective, the target duration to restore acceptable service behavior after disruption. | Resilience and Recovery |
| RPC Deadline | A maximum allowed duration for a remote call before automatic cancellation and timeout failure. | gRPC Constraints and Goals, Service Contracts with gRPC |
| RPC Streaming | A call style where request or response messages are sent as a stream instead of a single payload. | gRPC Constraints and Goals, Service Contracts with gRPC |
| Runbook | An operational playbook with stepwise actions for known incident classes. | Resilience and Recovery |
| SAGA | A distributed transaction pattern that coordinates a workflow through local transactions and compensating actions. | Event-Driven Messaging |
| SAGA Choreography | A saga style where services coordinate through emitted events without a central coordinator. | Event-Driven Messaging |
| SAGA Orchestration | A saga style where one coordinator controls workflow steps and compensation commands. | Event-Driven Messaging |
| Schema Constraint | A data rule enforced at model or storage level to protect consistency. | State and Data Modeling |
| Separation of Concerns | A design rule that keeps unrelated responsibilities in separate modules. | Single Responsibility Principle, Onion Architecture, Modularity and Composition |
| Service | A software program that exposes functionality through a published technical interface to other programs. | Introduction to Services |
| Service Agent | An intermediary runtime component that mediates service interaction through routing, policy enforcement, or message transformation. | Introduction to Services |
| Service Capability | A function offered by a service through a service contract. | Introduction to Services |
| Service Composition | An aggregate of services coordinated to automate a shared task. | Introduction to Services, Modularity and Composition |
| Service Consumer | The runtime role assumed by a software program that invokes and interacts with a service. | Introduction to Services |
| Service Contract | The published technical agreement that defines service operations, data schemas, policies, and fault semantics. | Introduction to Services, Abstraction and Boundaries |
| Hypermedia Link Relation | A typed link in a representation that describes an available transition or related resource. | Service Contracts with REST, REST Constraints and Goals |
| Late Binding | A runtime interaction model where clients discover next transitions from contract metadata and link relations instead of hardcoded route assumptions. | Service Contracts with REST |
| Uniform Contract | A stable contract model that uses consistent resource, method, representation, and status semantics across service capabilities. | Service Contracts with REST, REST Constraints and Goals |
| Service-Oriented Architecture | An architecture style that structures enterprise systems around contract-driven service capabilities and composition. | Introduction to Services |
| Service-Oriented Computing | The broader computing discipline that studies service publication, discovery, interaction, and composition models. | Introduction to Services |
| Service Level Target | A numeric performance or reliability objective for one service behavior. | Measurement and Performance, Resilience and Recovery |
| Server Reflection (gRPC) | A runtime capability that exposes service and method descriptors for tooling, debugging, and dynamic clients. | Service Contracts with gRPC |
| Strangler Migration Pattern | A phased migration method that replaces legacy or monolith capabilities incrementally with new service boundaries. | Microservices Architectural Style, Modern Monolith Architecture |
| Competing Consumers | A message-driven pattern where multiple workers consume from the same queue to increase throughput. | Message-Driven Architecture |
| Dead Letter Queue | A queue that receives messages that cannot be processed successfully after retry policy is exhausted. | Message-Driven Architecture, Event-Driven Messaging |
| Command Message | A message that requests execution of a specific business task by a consumer service. | Message-Driven Architecture |
| Single Responsibility Principle | A rule that each unit should have one reason for change. | Single Responsibility Principle, Simplicity First, Modularity and Composition, Class Design |
| Smoke Test | A fast critical-path verification that checks whether a build or deployment is viable for deeper test stages. | Smoke Testing, Integration and Functional Testing |
| Span ID | The identifier for one timed operation unit inside a distributed trace. | Observability in Microservices, Logs vs Metrics vs Traces |
| Sorting | A query operation that defines result order by one or more fields. | Landing Page |
| State | The stored memory of facts that define current system condition. | State and Data Modeling |
| Stateless Service | A service design where request processing keeps no durable local state and relies on external sources of truth for persistence. | The Database Dilemma |
| Structural Typing | A typing model where compatibility depends on member shape instead of explicit inheritance declarations. | Liskov Substitution Principle |
| Fat Interface | A broad interface that mixes unrelated capabilities and forces unused dependencies into clients. | Interface Segregation Principle |
| Text Search | A query operation that matches terms across textual fields. | Landing Page |
| Team Topologies | A team design model that defines interaction modes and ownership boundaries to keep delivery flow stable at scale. | Microservices Architectural Style |
| Throughput | The amount of completed work per unit of time. | Measurement and Performance |
| Timeout | A maximum wait duration for an operation before forced termination. | Resilience and Recovery |
| Span | A timed operation unit inside a distributed trace that represents one step in a request path. | Logs vs Metrics vs Traces, Correlation IDs |
| Trace | A distributed timing record that tracks request path across services. | Logs vs Metrics vs Traces, Measurement and Performance, Correlation IDs |
| Trace ID | The identifier that binds all spans belonging to one end-to-end distributed transaction. | Observability in Microservices, Correlation IDs |
| Trace Context | A standard propagation model for trace and request metadata across service boundaries, commonly carried in transport headers. | Correlation IDs, Observability in Microservices, Service Contracts with REST |
| Transition System | A model where domain state changes occur through explicit events or commands under invariant-preserving rules. | State and Data Modeling |
| Transaction Boundary | The exact set of state changes that must commit or rollback as one logical unit. | The Database Dilemma, State and Data Modeling |
| Trait (Rust) | A Rust language contract that defines behavior signatures that many concrete types can implement. | Open-Closed Principle, Dependency Injection |
| Trait Object (Rust) | A runtime polymorphism form in Rust, often Box<dyn Trait>, used to store heterogeneous implementations behind one behavior contract. |
Open-Closed Principle, Dependency Injection |
| Transport Layer | The communication mechanism that carries messages between components or services. | Onion Architecture |
| Unary RPC | A remote call pattern with one request message and one response message. | gRPC Constraints and Goals, Service Contracts with gRPC |
| Unit of Work | A transactional boundary that groups state changes into one commit decision. | Onion Architecture |
| System Under Test (SUT) | The specific function, method, class, or module currently being exercised by a test case. | Unit Testing, Correctness |
| Unit Test | A fast test that verifies one behavior unit in isolation. | Unit Testing, Correctness |
| Use Case | An application layer operation that orchestrates one business interaction. | Onion Architecture |
| Value Object | A domain object defined by value and immutability rules, not identity. | Onion Architecture |
| Versioned Contract | A shared interface or message model that carries explicit version evolution rules. | State and Data Modeling, Onion Architecture |
| Visibility | Access scope rules for class members such as public, protected, and private. | Class Design |
| Subject (Observer Pattern) | The publisher role that emits state change notifications to registered observers. | Observer Pattern |
| Workload Identity | A cryptographically verifiable identity assigned to a service or process for authenticated service-to-service authorization. | Zero Trust Architecture, gRPC Constraints and Goals |
| Zero Trust Architecture | A security architecture model where every access request is explicitly verified, least privilege is enforced, and trust is continuously re-evaluated. | Zero Trust Architecture, Resilience and Recovery |