Vocabulary of Software Architecture Patterns: Definitions and Usage in Context
Key English vocabulary for software architecture discussions — monolith, microservices, CQRS, event sourcing, bounded context, and more, with usage examples for meetings and design docs.
Software architecture discussions have a dense technical vocabulary that non-native English speakers often encounter before they have fully absorbed how to use the terms naturally in conversation. Knowing the definition of “CQRS” and being able to say “we should consider applying CQRS to the order service” in a design meeting are two different skills. This guide covers eight core architecture terms with definitions, context, and example sentences for use in technical discussions and documentation.
1. Monolith
Definition
A monolith (or monolithic architecture) is a single deployable unit that contains all application functionality — the user interface, business logic, and data access layer are packaged and deployed together. It is the default starting point for most applications.
Usage Notes
“Monolith” is often used descriptively (neutral) or pejoratively (implying the system has grown too large to manage easily). Context matters.
Example Sentences
- “The current system is a monolith — all services share a single database and are deployed as one unit.”
- “Before we discuss splitting this into microservices, let’s be honest about whether the monolith is actually causing us problems.”
- “We’re operating a modular monolith — the code is organised into clear modules, but it still deploys as a single artefact.”
- “The argument for the modular monolith is that it’s simpler to operate and debug at our current scale.”
2. Microservices
Definition
A microservices architecture decomposes an application into small, independently deployable services, each responsible for a specific business capability. Each service runs in its own process and communicates over a network, typically via HTTP or messaging.
Usage Notes
Microservices are frequently discussed alongside their trade-offs — increased operational complexity, network latency, and distributed systems challenges.
Example Sentences
- “We’ve decomposed the platform into microservices — each domain (payments, inventory, shipping) is an independent deployable.”
- “The move to microservices gave us deployment independence, but we’ve had to invest significantly in observability and service orchestration.”
- “For a team of five engineers, I’d question whether a microservices architecture is the right choice at this stage.”
- “The payments service is our most critical microservice — it has its own database and its own release cycle.”
3. Service Mesh
Definition
A service mesh is an infrastructure layer that handles service-to-service communication within a microservices architecture. It manages concerns like load balancing, service discovery, retries, circuit breaking, mutual TLS, and observability — typically without requiring application code changes.
Example Sentences
- “We’re evaluating whether to introduce a service mesh — it would give us traffic management and mutual TLS between services without application-level changes.”
- “The service mesh handles our retry policies — the individual services don’t need to implement that logic themselves.”
- “One of the arguments against a service mesh at our scale is the operational complexity of managing the sidecar proxies.”
4. Hexagonal Architecture (Ports and Adapters)
Definition
Hexagonal architecture, also known as ports and adapters, is a design pattern that isolates the core application logic from external systems (databases, APIs, UIs) through defined interfaces (ports) and interchangeable implementations (adapters). The goal is to make the core logic testable and independent of infrastructure concerns.
Usage Notes
This pattern is often discussed in the context of testability and clean architecture.
Example Sentences
- “We’ve structured the service around hexagonal architecture — the domain logic doesn’t depend on the database directly; it talks to a port, and the adapter handles the actual persistence.”
- “One benefit of ports and adapters is that you can swap the database for an in-memory implementation in tests without changing the core logic.”
- “The hexagonal architecture pattern makes it clear which parts of the codebase should be insulated from infrastructure decisions.”
5. CQRS (Command Query Responsibility Segregation)
Definition
CQRS separates the model used for updating state (commands) from the model used for reading state (queries). Instead of a single model handling both reads and writes, you have distinct models — and often distinct data stores — optimised for each purpose.
Usage Notes
CQRS is often used alongside event sourcing, and discussions of CQRS typically involve justifying the added complexity.
Example Sentences
- “We’re applying CQRS to the reporting module — the read model is a denormalised projection optimised for query performance.”
- “CQRS makes the most sense when read and write patterns are significantly different — otherwise the complexity may not be justified.”
- “The write side uses the command model to validate and persist business events; the read side rebuilds the view from those events.”
- “One challenge with CQRS is ensuring the read model stays consistent with the write model — especially in high-throughput systems.”
6. Event Sourcing
Definition
Event sourcing is a pattern in which the state of an application is derived from a sequence of immutable events, rather than stored directly. Instead of saving the current state of a record, you save a log of all events that led to that state, and the current state is reconstructed by replaying the event log.
Example Sentences
- “We’re using event sourcing for the order service — every state change (created, paid, shipped, cancelled) is stored as an immutable event.”
- “Event sourcing gives us a full audit trail out of the box — we can reconstruct the state of any order at any point in time.”
- “One trade-off with event sourcing is that querying the current state requires replaying events, which is why it’s often paired with CQRS and a read model.”
- “Migrating an existing system to event sourcing is non-trivial — it’s much easier to introduce it at the beginning of a new service.”
7. Eventual Consistency
Definition
Eventual consistency is a consistency model used in distributed systems where, after an update, all replicas of the data will eventually converge to the same state — but there is no guarantee of immediate consistency across all nodes.
Usage Notes
Eventual consistency is contrasted with strong consistency (all reads return the most recent write). Understanding when to accept eventual consistency is a key design decision.
Example Sentences
- “The search index operates under eventual consistency — it may take up to 30 seconds for a new product to appear in search results after it’s created.”
- “We’ve accepted eventual consistency in this part of the system in exchange for higher availability and write throughput.”
- “It’s important that the product team understands the eventual consistency model here — users may not see their changes reflected immediately.”
- “Strong consistency is available, but the latency cost at this scale makes eventual consistency the right trade-off for non-critical reads.”
8. Bounded Context
Definition
A bounded context is a Domain-Driven Design (DDD) concept that defines the explicit boundary within which a particular domain model is valid and consistent. Different bounded contexts may use the same terms with different meanings, and they interact through well-defined contracts.
Example Sentences
- “We’ve defined three bounded contexts in this domain: Ordering, Fulfilment, and Customer. They have separate models and communicate via events.”
- “The term ‘customer’ means something different in the Billing bounded context than in the CRM — each has its own model.”
- “Keeping the bounded contexts separate has made it much easier to evolve each service independently.”
- “The integration between bounded contexts is handled through a shared kernel and anti-corruption layers.”
Architecture Vocabulary Glossary Table
| Term | One-Line Definition |
|---|---|
| Monolith | Single deployable unit containing all application functionality |
| Microservices | Decomposed, independently deployable services per business capability |
| Service mesh | Infrastructure layer managing service-to-service communication |
| Hexagonal architecture | Core logic isolated from infrastructure via ports and adapters |
| CQRS | Separate models for read and write operations |
| Event sourcing | State derived from a replay of immutable stored events |
| Eventual consistency | Distributed system model where replicas converge over time |
| Bounded context | DDD boundary within which a domain model is consistent and valid |
| Anti-corruption layer | Translation layer that prevents a legacy or foreign model from polluting a new model |
| Saga pattern | A way to manage distributed transactions across multiple services |
Key Takeaways
- Architecture vocabulary is most useful when you know not just the definition but how to use the term in a sentence in a meeting or design doc.
- Many architecture patterns involve explicit trade-offs — naming the trade-off (“the complexity may not be justified at our scale”) signals architectural maturity.
- Patterns like CQRS and event sourcing are often combined — knowing how they relate gives you more fluent technical conversation.
- A bounded context is one of the most important concepts in large-scale system design — it clarifies ownership, terminology, and integration contracts.