Terminology

2225 terms, tools, patterns and metrics an architect is expected to use precisely. Each one gets a short explanation of what it is, and — where it matters — what it is commonly confused with. Search filters as you type; the column headers sort.

All areas2225 Architecture Fundamentals77 Distributed Systems107 Data Architecture110 Cloud Architecture94 Networking88 API & Integration Architecture82 Reliability & Resilience75 Observability70 Performance & Capacity Engineering72 Security Architecture86 Cost Architecture & FinOps71 Business Architecture67 Architecture Communication67 Enterprise Architecture66 Legacy Modernization71 AI-Era Architecture74 Software Architecture & Engineering71 Architecture Patterns71 Architecture Decision-Making63 The Architect's Meta-Skills61 Delivery & Release Engineering66 Platform Engineering & Developer Experience70 Testing & Quality Architecture66 Data Platform Architecture69 Streaming & Real-Time Data69 Data Governance & Semantics74 Frontend & Experience Architecture66 Edge, Mobile & IoT68 Regulatory & Data Protection Architecture65 Assurance, Audit & Model Risk69

Kind Any concept801 practice736 pattern377 metric127 case-study77 tool62 protocol45

71 terms shown.

Term	Kind	Topic	What it is
Adapter Conformance Suite Port Conformance Tests, Shared Adapter Test Suite	pattern	Hexagonal Architecture	One test suite written against a port and run against every implementation including the in-memory fake, so the fake cannot promise behaviour the real adapter does not deliver.
Aggregate	pattern	Domain-Driven Design	A cluster of objects treated as a single unit for data changes, with one root through which all modification passes, defining the consistency boundary.
Anaemic Domain Model	concept	Domain-Driven Design	Objects that hold data with no behaviour, leaving business rules scattered across service classes where they are duplicated and inconsistently applied.
Architectural Significance Architecturally Significant Decision, Significance Test	concept	Software Architecture	The test that separates decisions worth reviewing from the ones a team should make alone, by asking what undoing each one would cost rather than how technical it sounds.
Architecture Fitness Test Dependency Rule Test, Architecture Unit Test, Boundary Enforcement	practice	Modular Monolith	An automated check in the build that fails when code violates the intended module dependency rules - the mechanism that decides whether architectural boundaries survive schedule pressure or erode within months.
Bidirectional Contract	pattern	Contract Tests	A contract verified from both sides — the consumer's expectations and the provider's actual behaviour — without either running the other's tests directly.
Blue-Green Database Schema	pattern	Release Strategies	The constraint that makes fast rollback actually work — both application versions must be able to run against one schema at the same time.
Boundary Reversal Asymmetry Split Reversal Cost, Asymmetric Boundary Error	concept	Service Boundaries	The fact that a boundary drawn too coarse is cheap to split later while one drawn too fine is expensive to merge, which makes the coarse error the right default when evidence is thin.
Boundary Volatility Test	practice	Service Boundaries	Evaluating a proposed service boundary by asking whether the things on either side change for different reasons and at different rates.
Bounded Context	concept	Bounded Contexts	A boundary within which a model and its vocabulary are internally consistent, and outside which the same words may legitimately mean something different.
Branch by Abstraction	pattern	Refactoring	Making a large change incrementally on the trunk by introducing an abstraction over the old implementation, building the new one behind it, then removing the abstraction.
Branch Lifetime	metric	Trunk-Based Development	How long a branch lives before being merged, which determines integration pain and is the practical measure of whether integration is continuous.
CI/CD Continuous Integration, Continuous Delivery	practice	CI/CD	Integrating continuously and keeping the software always releasable — a discipline about batch size, with automation as its enabler.
Clean Architecture Onion Architecture	pattern	Clean Architecture	Concentric layers with dependencies pointing inward, so business rules know nothing about frameworks, databases or delivery mechanisms.
Co-Change Analysis Change Coupling, Logical Coupling	practice	Service Boundaries	Using version-control history to find which components change together - the strongest available evidence that a proposed boundary is right or wrong.
Code Review	practice	Code Review	Peer inspection before merge — valuable for knowledge sharing and design feedback, and reliably harmful when it becomes a latency bottleneck.
Context Map	practice	Bounded Contexts	A diagram of the bounded contexts in a system and the relationship type between each pair, making integration expectations and power dynamics explicit.
Debt Interest Rate Cost Per Unit Time, Debt Triage Axis	concept	Technical Debt	How much a piece of technical debt costs per unit time in slowed delivery, incidents and effort - which, paired with the cost to fix, is what separates debt worth paying down from debt that merely looks unpleasant.
Debt Register	practice	Technical Debt	A maintained record of known technical compromises with their cost, impact and repayment trigger, making debt manageable rather than merely felt.
Dependency Inversion	concept	SOLID	The rule that high-level policy should not depend on low-level detail, both depending instead on an abstraction owned by the policy.
Dependency Rule	concept	Clean Architecture	The constraint that source-code dependencies may point only inward, from detail toward policy, regardless of the direction of control flow.
Deployability Test Can You Deploy Alone, Boundary Justification Test	practice	Microservices	Asking whether one team can change, deploy and roll back a service without telling the others - the single test that distinguishes a boundary delivering independence from one delivering only cost.
Design Patterns	concept	Design Patterns	Named solutions to recurring design problems — valuable primarily as shared vocabulary, and harmful when applied as a goal.
Distributed Monolith	concept	Microservices	A system split into services that must still be deployed, changed and operated together, incurring distribution costs without independence.
Domain-Driven Design DDD	practice	Software Architecture	Modelling software around the business domain, with boundaries drawn where the language of the business changes.
DoorDash: Decomposing a Python Monolith DoorDash Microservices Migration	case-study	Service Boundaries	DoorDash moved off a Python monolith as growth made deployment risk and scaling limits unmanageable, and used a facade to migrate incrementally.
DORA Metrics	metric	DORA Metrics	Four measures of software delivery — deployment frequency, lead time, change failure rate, time to restore — that resist gaming better than most.
Etsy's Continuous Deployment	case-study	Software Architecture	Etsy moved from infrequent, risky releases to dozens of deploys a day, demonstrating that deployment frequency and stability improve together rather than trading off.
Feature Flags Feature Toggles	pattern	Feature Flags	Decoupling deployment from release, so code ships continuously and exposure is a runtime decision — with a lifecycle that must be enforced.
Flag Change Provenance Flag Audit Trail, Configuration Provenance	practice	Feature Flags	Recording who changed a flag, when, from what to what - and, separately, stamping the effective configuration version onto every artefact it influenced, because the first cannot reconstruct the second.
Flag Debt	concept	Feature Flags	The accumulating complexity of feature flags that are never removed, producing untested code paths and combinatorial behaviour nobody understands.
Flag Expiry Discipline Flag Lifecycle, Stale Flag Removal	practice	Feature Flags	Creating every flag with an owner and an expiry date and treating removal as part of the rollout's definition of done - because flags have a creation process and, without this, no removal process.
Hexagonal Architecture in Practice Ports and Adapters	pattern	Hexagonal Architecture	The application defines ports; adapters implement them — so the same core is driven by HTTP, a queue, or a test with no changes.
Independent Deployability	concept	Microservices	The property that a service can be released to production without coordinated release of any other, which is the defining benefit of microservices.
Invariant Containment Boundary Follows the Invariant, Transaction Test	concept	Service Boundaries	The rule that a service boundary must contain any invariant that must hold exactly - so discovering that a split would break a transaction is evidence the boundary is wrong, not merely an obstacle.
Knight Capital: $440 Million in 45 Minutes Knight Capital Incident	case-study	Feature Flags	A deployment that reached seven of eight servers, combined with a reused feature flag, activated dormant test code and destroyed the company in three quarters of an hour.
LinkedIn Project Inversion: Stopping to Fix the Road Inversion	case-study	Technical Debt	LinkedIn halted feature development for roughly two months to rebuild its deployment and development infrastructure, because the tooling had become the constraint on everything.
Microservices	pattern	Software Architecture	An architectural style where an application is a set of independently deployable services, each owning its data and aligned to a business capability.
Modular Monolith Boundaries	pattern	Modular Monolith	A single deployable unit with strictly enforced internal module boundaries, giving domain separation without distribution.
Module Dependency Enforcement	practice	Modular Monolith	Automated checks that prevent one module from importing another's internals, giving a monolith the boundary discipline of separate services.
Module Public Surface Module Exported Surface, Module Entry Points	concept	Modular Monolith	The set of types a module lets other modules reach, which decides how much of it can be rewritten or extracted without touching anyone else's code.
Monzo's Microservice Estate	case-study	Software Architecture	Monzo runs a bank on well over a thousand microservices, and the interesting engineering is in the platform and network isolation that makes that number survivable.
Pattern Overuse	concept	Design Patterns	Applying a design pattern where the problem it solves does not exist, adding indirection and vocabulary without benefit.
Pipeline Feedback Latency Commit-to-Verdict Time, CI Feedback Time	metric	CI/CD	The time from pushing a change to knowing whether it passed, which sets the batch size engineers choose and therefore the size of every review, deploy and rollback.
Port and Adapter	pattern	Hexagonal Architecture	An interface defined by the application expressing what it needs, paired with an implementation that connects it to a specific technology.
Preparatory Refactoring Enabling Refactor, Prepare-Then-Change	practice	Refactoring	Reshaping existing code first so the behaviour change that follows is small, keeping the two in separate commits with separate claims about what is true.
Quality Ratchet Boy Scout Rule, Improvement Ratchet	practice	Refactoring	An automated rule ensuring a codebase can only improve on a chosen dimension - new code meets the standard, existing code improves when touched, and regression is blocked.
Refactoring	practice	Software Architecture	Changing the internal structure of code without changing its external behaviour, in small verified steps.
Refactoring Under Test	practice	Refactoring	Changing internal structure without changing behaviour, with tests as the mechanism that makes the claim verifiable.
Release Strategies	pattern	Release Strategies	How new code reaches users — rolling, blue-green, canary, or flag-controlled — chosen by rollback speed and blast radius.
Release Toggle Temporary Feature Flag, Rollout Flag, Deploy-Release Decoupler	pattern	Feature Flags	A short-lived flag that decouples deploying code from releasing a feature, intended to be removed within weeks - and the category responsible for almost all accumulated feature-flag debt when it is not.
Review Latency	metric	Code Review	The time between a change being ready for review and the review happening, which is usually the largest component of lead time.
Service Boundary	concept	Software Architecture	The line separating what one service owns and is accountable for from what it must ask another service about.
Service Boundary Heuristics	practice	Service Boundaries	The signals that indicate where a service boundary belongs, and the ones that reliably mislead.
Shadow Planning Plan Shadowing, Shadow Query Planning, Dry-Run Routing	practice	Refactoring	Running a new routing or planning layer over live production traffic without serving its results, so the work it cannot handle is enumerated from real usage rather than from reading code.
Shared Kernel Shared Model, Common Domain Library	pattern	Bounded Contexts	A deliberately shared subset of the domain model between two contexts, which removes translation cost by accepting a shared release cadence - the one context relationship that couples teams on purpose.
Shopify: A Monolith That Scaled Packwerk, Shopify Pods	case-study	Modular Monolith	Shopify kept its Rails monolith and invested in enforced internal boundaries and horizontal sharding, rather than decomposing into microservices.
Software Contract Tests	practice	Contract Tests	Verifying an interaction between two components from both sides independently, so integration confidence does not require deploying both.
SOLID	practice	Software Architecture	Five object-oriented design principles — single responsibility, open/closed, Liskov substitution, interface segregation, dependency inversion.
SOLID Principles	concept	SOLID	Five object-design principles whose architectural value lies almost entirely in the last one — dependency inversion.