- C4 Model — A lightweight architecture visualization approach that describes software systems across four levels: System Context, Container, Component, and Code.
- System Context Diagram — C4 level 1 diagram showing a software system and its interactions with users and other external systems.
- Container Diagram — C4 level 2 diagram showing the deployable/executable units (applications, services, databases) that make up a software system.
- Component Diagram — C4 level 3 diagram decomposing a container into groups of related functionality (components) and their collaborations.
- Code Diagram — C4 level 4 diagram showing the implementation-level details (classes, interfaces, functions) of a component.
- Architecture Decision Record (ADR) — A short document capturing a single architecturally significant decision, its context, and its consequences.
- Architecture Drift — The widening gap between documented architecture and the system that actually runs in production.
- Conformance Rule — A machine-checkable constraint that validates the codebase against architectural intent.
- Architecture as Code — Describing system architecture in a versioned, text-based format so it can be reviewed, diffed, and validated like source code.
- Technology Radar — A curated catalog of technologies grouped into rings (adopt / trial / assess / hold) that guides engineering choices.
- DORA Metrics — Four widely used engineering performance metrics: Deployment Frequency, Lead Time for Changes, Change Failure Rate, and Mean Time to Recovery.
- Deployment Frequency — How often a team successfully ships code to production. One of the four DORA metrics.
- Lead Time for Changes — The time between a code change being committed and that change running in production.
- Change Failure Rate — The percentage of deployments that cause a degradation in production and require remediation.
- Mean Time to Recovery (MTTR) — The average time it takes to restore service after a production incident.
- Domain-Driven Design (DDD) — An approach to software design that centers the model and language of the business domain.
- Hexagonal Architecture — A layered architecture style that isolates domain logic from infrastructure via ports and adapters.
- Clean Architecture — A layered architecture where dependencies point inward toward the domain, popularized by Robert C. Martin.
- Event Storming — A collaborative modeling workshop that uses sticky notes representing domain events to map a business process.
- Microservices — An architectural style that structures an application as a collection of small, independently deployable services organized around business capabilities.
- Service Mesh — A dedicated infrastructure layer for handling service-to-service communication, typically via sidecar proxies.
- API Contract — A formal specification of an API (OpenAPI, gRPC proto, GraphQL schema) that producers and consumers agree to uphold.
- Event Channel — A named, typed stream of events (often Kafka topic or equivalent) through which services publish and subscribe asynchronously.
- Ownership Map — A mapping from system elements (services, modules, pipelines) to the team or person accountable for them.
- Living Documentation — Documentation that is generated or validated from the running system, so it stays accurate as the system evolves.
- MCP Server — A server implementing the Model Context Protocol so AI coding assistants can query project context through a standardized tool interface.
Software Architecture Glossary
Concise definitions of the C4 model, DORA metrics, ADRs, architecture drift, clean architecture, and other terms every software team should know. Curated by Archyl.