Terminology

2185 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 areas2185 Architecture Fundamentals77 Distributed Systems107 Data Architecture110 Cloud Architecture89 Networking88 API & Integration Architecture82 Reliability & Resilience75 Observability70 Performance & Capacity Engineering72 Security Architecture81 Cost Architecture & FinOps66 Business Architecture67 Architecture Communication67 Enterprise Architecture66 Legacy Modernization66 AI-Era Architecture69 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 Architecture64 Streaming & Real-Time Data69 Data Governance & Semantics69 Frontend & Experience Architecture66 Edge, Mobile & IoT68 Regulatory & Data Protection Architecture65 Assurance, Audit & Model Risk64

Kind Any concept785 practice729 pattern362 metric125 case-study77 tool62 protocol45

23 terms shown.

Term	Kind	Topic	What it is
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.
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.
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.
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 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.
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.
Domain-Driven Design DDD	practice	Software Architecture	Modelling software around the business domain, with boundaries drawn where the language of the business changes.
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 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.
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.
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.
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.
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.
Testing Strategies	practice	Testing Strategies	Choosing what to test at which level, optimising for confidence per unit of time and maintenance rather than for coverage.
Trunk-Based Development in Practice	practice	Trunk-Based Development	Everyone integrates to one shared branch at least daily, with incomplete work hidden behind flags rather than isolated in branches.
Ubiquitous Language	practice	Domain-Driven Design	A shared vocabulary used identically by domain experts and in the code, so that translation between business and implementation is unnecessary.