software-architecture-design

index

16 min read

Wiki Index

One-line summary per page. Start queries from wiki/topics/ (synthesis), drill into wiki/concepts/ (detail), or check wiki/sources/ (origin).

Topics (Synthesis & Navigation)

Concepts (A–Z)

  • Abstract Factory Pattern — creational pattern for families of related objects without specifying concrete classes
  • Abstraction — hiding complexity behind interfaces; a core design principle
  • Actor Model Architecture — concurrency model using message-passing actors; no shared mutable state
  • Adapter Pattern — structural pattern converting one interface to another expected by clients
  • Aggregate — DDD cluster of entities/value objects with a single root enforcing all invariants
  • Ambassador Pattern — proxy sidecar that offloads cross-cutting network concerns from a service
  • Anti-Corruption Layer Pattern — translation boundary protecting a domain model from external model pollution
  • Apache Kafka — distributed event streaming platform; durable, ordered, partitioned log
  • API Design Principles — versioning, idempotency, pagination, error conventions
  • API Gateway Pattern — single entry point for client requests; handles routing, auth, rate-limiting
  • Architectural Decision Records (ADR) — documents capturing significant decisions with context, options, and consequences
  • Architectural Styles and Patterns — overview of the landscape of architectural styles
  • Architecture Erosion — how architectural intent degrades over time and how to prevent it
  • Backend for Frontend Pattern — dedicated API gateway tailored to a specific client type
  • Backpressure — mechanism for consumers to signal producers to slow down in reactive systems
  • BASE vs ACID — database consistency property sets: strong (ACID) vs available (BASE) trade-offs
  • Behavior-Driven Development — test specification in human-readable Given/When/Then format
  • Blue-Green Deployment — zero-downtime deployment using two identical production environments
  • Bounded Context — DDD explicit boundary where a specific domain model and ubiquitous language apply
  • Bridge Pattern — structural pattern decoupling abstraction from implementation so both can vary independently
  • Brooks’s Law — adding manpower to a late software project makes it later; n(n-1)/2 communication overhead
  • Builder Pattern — creational pattern separating complex object construction from its representation
  • Bulkhead Pattern — isolates failures by partitioning resources into isolated pools
  • Canary Release — gradual production rollout to a small subset of users before full deployment
  • CAP Theorem — distributed stores can guarantee at most 2 of: Consistency, Availability, Partition Tolerance
  • Chain of Responsibility Pattern — passes request along a handler chain until one handles it
  • Choreography vs Orchestration — event-reactive flow vs. central coordinator; Saga topology choice
  • Circuit Breaker Pattern — trips to open state on failure threshold; prevents cascading failures
  • Clean Architecture — concentric layer architecture enforcing inward dependency rule
  • Command Pattern — encapsulates a request as an object; enables undo, queue, log
  • Composite Pattern — structural pattern composing objects into tree structures
  • Composition over Inheritance — favor object composition over class inheritance for flexibility
  • Conceptual Integrity — architectural clarity and consistency; Mythical Man Month concept
  • Consistency Models — full spectrum: Linearizability → Sequential → Causal → FIFO → Eventual; data-centric and client-centric
  • Consumer-Driven Contract Testing — consumer defines contract; provider verifies against it
  • Continuous Integration and Delivery — CI/CD pipeline: automated build, test, deploy
  • Conway’s Law — system structure mirrors the communication structure of the organization that built it
  • Coupling and Cohesion — foundational design quality metrics; high cohesion, low coupling
  • CQRS — separates read model from write model; each optimized independently
  • Dapr — CNCF sidecar runtime with 10 distributed building blocks (pub/sub, state, actors, workflow)
  • Decorator Pattern — structural pattern adding behavior to objects without subclassing
  • Dependency Injection — providing dependencies from the outside rather than constructing them internally
  • Dependency Inversion Principle — high-level modules should not depend on low-level modules; both depend on abstractions
  • Distributed Tracing — tracks requests across services as spans within a trace; OpenTelemetry standard
  • Distributed Transactions — ACID transactions spanning multiple services; costly but strongly consistent
  • Domain Event — immutable record of a significant domain occurrence; past tense, carries all relevant data
  • Domain-Driven Design — software built around deep domain model; ubiquitous language, bounded contexts
  • DRY Principle — Don’t Repeat Yourself; single authoritative source for every piece of knowledge
  • Encapsulation — hiding internal state; exposing only necessary interfaces
  • Enterprise Integration Patterns — canonical patterns for messaging-based integration (EIP)
  • etcd — CNCF Raft-based CP distributed key-value store; Kubernetes cluster state backing store
  • Event Notification Pattern — thin events as signals; consumers call back for details; minimal payload coupling
  • Event Sourcing — state derived from append-only event log; enables temporal queries and full audit trail
  • Event Sourcing and CQRS Integration — ES write-side + CQRS read-side projections; Kafka-based Single Views
  • Event Storming — collaborative workshop for discovering domain events and bounded contexts
  • Event Upcasting — transforms old event payloads to current schema on read; handles schema evolution
  • Event-Carried State Transfer — fat events with full state payload; temporal decoupling; no callback needed
  • Event-Driven Architecture — components communicate via events through a broker; loose coupling
  • Eventual Consistency — system converges to consistent state given no new updates; AP systems’ model
  • Facade Pattern — structural pattern providing simplified interface to a complex subsystem
  • Factory Method Pattern — creational pattern deferring object creation to subclasses
  • Feature Flags — runtime toggle for enabling/disabling features without deployment
  • Flyweight Pattern — structural pattern sharing state between many fine-grained objects
  • Gossip Protocol — epidemic peer-to-peer state dissemination; O(log N) convergence; decentralized
  • GraphQL — query language for APIs; clients specify exact data shape; single endpoint
  • gRPC — high-performance RPC framework using Protocol Buffers; strong typing, streaming
  • Hexagonal Architecture — ports and adapters; isolates domain from infrastructure; full testability
  • Idempotency — operations that produce the same result regardless of how many times executed
  • Inbox Pattern — idempotent message reception; deduplicates incoming messages before processing
  • Information Hiding — modules hide implementation details; only expose necessary interfaces
  • Infrastructure as Code — managing and provisioning infrastructure through code and version control
  • Integration Testing — testing interactions between components; beyond unit, before end-to-end
  • Interface Segregation Principle — clients should not depend on interfaces they don’t use
  • Iterator Pattern — behavioral pattern traversing a collection without exposing its representation
  • KISS Principle — Keep It Simple, Stupid; prefer simple solutions
  • Knowledge Level Pattern — base-level instances + meta-level type/rules; configurable behavior without code changes
  • Law of Demeter — a module should not know about the internals of the objects it manipulates
  • Layered Architecture — horizontal layers (presentation, business, data); classic n-tier
  • Lazy Initialization — defer object creation until first use
  • Liskov Substitution Principle — subtypes must be substitutable for their base types
  • Mechanical Sympathy — designing software aligned to hardware behavior (cache lines, memory access, false sharing)
  • Mediator Pattern — behavioral pattern centralizing communication between components
  • Memento Pattern — behavioral pattern capturing and restoring object state
  • Message Broker — intermediary routing messages between producers and consumers
  • Message Queue — asynchronous point-to-point message delivery with buffering
  • Microservices Architecture — independently deployable services organized around business capabilities
  • Modular Monolith — single deployable unit with enforced module boundaries; MonolithFirst strategy
  • Modularity — decomposing a system into loosely coupled, highly cohesive modules
  • MVC Pattern — separates domain model, presentation, and user input handling
  • MVVM Pattern — Model-View-ViewModel; data binding between view and view model
  • Object Pool Pattern — reuses expensive objects rather than creating and destroying them
  • Observability — infer internal system state from external outputs; three pillars: logs, metrics, traces
  • Observer Pattern — behavioral pattern; objects subscribe to state changes in a subject
  • Onion Architecture — concentric layers; domain at center; dependencies point inward
  • Open-Closed Principle — open for extension, closed for modification
  • Outbox Pattern — atomically writes DB record + outbox message; ensures reliable event publishing
  • PACELC Theorem — extends CAP: during partition choose A vs C; else choose Latency vs Consistency
  • Property-Based Testing — generates random inputs to test properties that should always hold
  • Prototype Pattern — creational pattern cloning existing objects
  • Proxy Pattern — structural pattern providing a surrogate or placeholder for another object
  • Publish-Subscribe Pattern — producers publish to topics; consumers subscribe independently
  • Quality Attributes — non-functional requirements: performance, scalability, reliability, security, maintainability
  • Raft Consensus Algorithm — leader election, log replication, safety; more understandable than Paxos
  • Reactive Architecture — systems that are responsive, resilient, elastic, and message-driven
  • Reactive Programming — programming with asynchronous data streams and propagation of change
  • Reactive Streams — specification for async stream processing with non-blocking backpressure
  • Repository Pattern — abstraction for persisting and retrieving aggregates; decouples domain from storage
  • Resiliency Patterns — circuit breaker, bulkhead, retry, timeout, fallback; preventing cascading failures
  • Responsibility Layers — DDD domain stratification: Capabilities → Operations → Policies → Commitments → Decision Support
  • REST — architectural style for distributed hypermedia systems; uniform interface, stateless
  • Retry Pattern — automatic retry of transient failures with backoff strategies
  • Richardson Maturity Model — levels 0–3 for REST API maturity
  • Saga Pattern — distributed transaction via local transactions + compensating transactions; no 2PC
  • Self-Healing Systems — MAML anomaly detection + GNN cascade prediction + RL recovery; autonomous remediation
  • Separation of Concerns — each module addresses a separate concern
  • Serverless Architecture — function-based execution; no server management; event-triggered
  • Service Mesh — infrastructure layer handling service-to-service communication (mTLS, routing, observability)
  • Service-Oriented Architecture — coarse-grained services communicating via standard protocols (SOAP, ESB)
  • Session Guarantees — client-centric consistency: Read-Your-Writes, Monotonic Reads, Monotonic Writes, Writes-Follow-Reads
  • Sidecar Pattern — deploys auxiliary component alongside primary service in separate process/container
  • Single Responsibility Principle — a class should have only one reason to change
  • Singleton Pattern — creational pattern ensuring a class has only one instance
  • Software Design vs Software Architecture — design is local decisions; architecture is system-wide decisions
  • State Pattern — behavioral pattern allowing an object to alter its behavior when its internal state changes
  • Strangler Fig Pattern — gradually replaces a legacy system by routing traffic to new implementation
  • Strategy Pattern — behavioral pattern defining a family of algorithms, encapsulating each one
  • Technical Debt — future rework implied by choosing an expedient solution now
  • Template Method Pattern — behavioral pattern defining algorithm skeleton; subclasses fill in steps
  • Test Double — umbrella term: mock, stub, fake, spy, dummy
  • Test Pyramid — unit tests at base, integration in middle, end-to-end at top; fast → slow ratio
  • Test-Driven Development — red-green-refactor cycle; tests drive design
  • Twelve-Factor App — 12 methodology principles for cloud-native, portable SaaS applications
  • Ubiquitous Language — DDD shared vocabulary embedded in code, tests, and conversation
  • Value Object — immutable DDD object defined entirely by its attributes; no identity
  • Vector Clock — logical timestamps tracking happened-before causality in distributed systems
  • Vertical Slice Architecture — organizes code by feature (slice through all layers) not by layer
  • Visitor Pattern — behavioral pattern separating algorithm from the object structure it operates on
  • YAGNI Principle — You Aren’t Gonna Need It; don’t add functionality until it is needed

Sources

Articles

Papers

Repos

5 items under this folder.