Architecture terms

8 terms of 1506 total

🏛️ The decisions that outlive the code that implements them

Software architecture is the set of decisions that are hard to reverse and expensive to get wrong. This category covers design patterns, structural patterns like microservices and event-driven systems, domain-driven design, scalability principles, and the trade-offs that shape how large systems are built and evolved over years. Good architecture does not happen by accident.

More on Architecture history · 6 references · key concepts

History

Software architecture emerged as a distinct discipline in the 1990s as systems grew too large for ad-hoc design, with seminal works like the Gang of Four's Design Patterns (1994) and later Fowler's Patterns of Enterprise Application Architecture (2002) establishing shared vocabulary. The rise of object-oriented programming and distributed systems created pressure to document architectural decisions and patterns, leading to frameworks like MVC (mid-1990s) and layered architectures that became industry standards. The 2000s saw domain-driven design (Evans, 2003) shift focus toward modeling business complexity, while the 2010s introduced microservices and event-driven architectures as responses to scaling and deployment challenges at cloud scale. Today's architecture practice balances competing concerns—consistency vs. availability (CAP theorem), monolithic simplicity vs. distributed resilience, and synchronous reliability vs. asynchronous scalability—using patterns like CQRS, event sourcing, and service mesh to manage complexity in cloud-native systems.

Key concepts

Monolithic Architecture
Microservices
Domain-Driven Design (DDD)
REST (Representational State Transfer)
API Gateway Pattern
Event-Driven Architecture
CQRS (Command Query Responsibility Segregation)
CAP Theorem

Best references

Domain-Driven Design: Tackling Complexity in the Heart of Software Eric Evans' seminal work establishing DDD principles, bounded contexts, and ubiquitous language—foundational for understanding domain modeling and architectural decisions in the glossary's DDD terms.
Building Microservices: Designing Fine-Grained Systems Sam Newman's authoritative guide covering microservices patterns, service boundaries, deployment, and organizational alignment—directly relevant to microservices, API patterns, and service mesh content.
The OpenAPI Specification Official specification for documenting REST APIs, widely adopted for standardizing API design and contracts—canonical reference for OpenAPI/Swagger Specification and REST API architecture.
Event Sourcing and CQRS Martin Fowler's widely-cited articles on CQRS and Event Sourcing patterns, providing practical guidance on command-query separation and event-driven architectures essential to the glossary.
Designing Data-Intensive Applications Martin Kleppmann's comprehensive reference on distributed systems concepts including CAP Theorem, eventual consistency, consensus algorithms, and vector clocks—core to distributed architecture understanding.
The Twelve-Factor App Heroku's methodology for building scalable, maintainable cloud applications—canonical reference for modern application architecture practices and deployment patterns.

🧠 Logic graph · Architecture

33 edges here

9 verbs used

36 terms touched

3 narratives

✦ Latest in Architecture

Typed relationships here

Edges touching a Architecture term.

Value Object Often seen in Bounded Context (DDD) 6d
Aggregate Design Heuristics Often seen in Event Sourcing Jun 16
API Gateway Pattern Leverages Circuit Breaker Pattern Jun 16
Strangler Fig Pattern Leverages API Gateway Pattern Jun 16
Aggregate Design Heuristics Often seen in Bounded Context (DDD) Jun 16

Exactly-once delivery connects to domain events through the outbox pattern, which atomically writes those events to a database table in the same transaction as the business data that produced them. The pattern is what carries the events safely to the broker without loss or duplication, so the delivery guarantee is meaningfully about the domain events being relayed — remove the outbox and there's no mechanism tying the messaging guarantee to the architectural event records. That atomic write is the load-bearing piece: it's the bridge between 'something happened in the domain' and 'the broker delivers it exactly once'.

Exactly-Once Delivery · by means of · 🪢 Transactional Outbox Pattern → Domain Events

SOLID reaches hexagonal architecture by means of the Dependency Inversion Principle, the one of its five letters that says modules should depend on abstractions rather than concrete implementations. Hexagonal architecture is essentially DIP made structural: its ports are exactly those abstractions, and its adapters are the concrete implementations kept on the far side of them. Without DIP as the mediator the link collapses to a vague 'good design' association — it's DIP specifically that supplies the interface-over-implementation rule that hexagonal's ports-and-adapters scheme realizes.

SOLID Principles (Overview) · by means of · 🪢 Dependency Inversion Principle (DIP) → Hexagonal Architecture (Ports & Adapters)

Dependency injection and hexagonal architecture meet at the dependency inversion principle: DI is the concrete technique that implements inversion by feeding abstractions into a class instead of letting it construct concrete dependencies, while hexagonal architecture realizes that same principle structurally through its ports (interfaces) and adapters (implementations). The mediator carries the shared commitment to depending on abstractions rather than concretions — that's precisely what lets hexagonal's core stay ignorant of HTTP or database details, because DI is how those adapters get wired into the ports at runtime. Without dependency inversion as the common contract, DI would just be a testability trick and hexagonal a layering diagram, with no principled reason they belong together.

Dependency Injection · by means of · 🪢 Dependency Inversion Principle (DIP) → Hexagonal Architecture (Ports & Adapters)