api: YAML JSON TOON Database
version: 1.0.0
format: yaml
dataset:
  id: 355
  slug: architectural-design-patterns
  title: Architectural Design Patterns
  description: "High-level structural patterns: MVC, MVVM, Microservices, Event-Driven, Layered, Hexagonal (Ports & Adapters), CQRS, Serverless, Service Mesh."
  category: Design Patterns
  category_slug: design-patterns
  tags: design-patterns,architectural,mvc,microservices,event-driven,serverless
  view_count: 2
  created_at: 1781275786
  updated_at: 1781275786
data:
  patterns:
    - name: MVC (Model-View-Controller)
      category: Component-Based
      description: "Separates application into three components: Model (data/business logic), View (UI presentation), Controller (input handling/orchestration). Promotes separation of concerns."
      key_principles:
        - "Separation of concerns: data, UI, control logic isolated"
        - Model notifies View of changes (Observer pattern)
        - Controller translates user input into model updates
        - View observes Model (data binding or pull)
        - Multiple Views can observe same Model
      benefits: Modular code structure, testability (test model/controller without UI), parallel development (frontend/backend), reusable models and views.
      tradeoffs: Controller can become God object (too much logic), tight coupling between Controller and View in some implementations, complexity for simple UIs, many files for small features.
      typical_components:
        - Model classes (data, validation, business rules)
        - View templates/UI components
        - Controller/Router (handles requests, updates model)
      when_to_use: Applications with rich UI requiring separation, web frameworks (Rails, Django, Spring MVC), desktop apps, team-based development where roles are split.
      tech_examples:
        - Ruby on Rails (MVC)
        - Django (MVC-like, MVT)
        - Spring MVC (Java)
        - ASP.NET MVC
        - Backbone.js (JS MVC)
        - Angular (MVVM variant)
    - name: MVVM (Model-View-ViewModel)
      category: Component-Based
      description: Evolution of MVC for data-binding UIs. View observes ViewModel via data binding; ViewModel exposes data/commands for View, no direct View reference. Model unchanged.
      key_principles:
        - Data binding between View and ViewModel (two-way)
        - ViewModel exposes observable properties (ObservableObject)
        - View handles only presentation (no logic)
        - Commands encapsulate actions (ICommand)
        - ViewModel is UI-agnostic (testable without UI)
      benefits: Excellent testability (ViewModel unit tests), designer-developer collaboration (designers work on XAML, devs on ViewModel), clean separation, reactive programming friendly.
      tradeoffs: Data binding can be opaque (hard to debug), memory leaks from event handlers, overkill for simple UIs, learning curve for binding syntax.
      typical_components:
        - Model (data layer)
        - View (XAML/HTML template)
        - ViewModel (bindable properties, commands)
        - Data binding engine (framework-provided)
      when_to_use: Applications with rich data binding (WPF, UWP, Xamarin, SwiftUI, Jetpack Compose), reactive UIs, teams with designer/developer split.
      tech_examples:
        - WPF (Windows Presentation Foundation)
        - Xamarin / .NET MAUI
        - SwiftUI (Apple)
        - Jetpack Compose (Android)
        - Vue.js (Vuex/Pinia inspired by MVVM)
        - Knockout.js
    - name: Microservices Architecture
      category: Distributed Systems
      description: Application as collection of small, independent services. Each service owns its data, runs in its own process, communicates via HTTP/gRPC/messaging. Independently deployable.
      key_principles:
        - Single responsibility per service (bounded context)
        - Decentralized data management (database per service)
        - Independent deployment and scaling
        - Technology diversity (polyglot)
        - Resilience (fault isolation)
        - Automated deployment (CI/CD)
      benefits: Independent scaling per service, team autonomy, tech stack flexibility, fault isolation (one service failure doesn't crash all), easier to understand codebase per service.
      tradeoffs: Complex distributed system (network latency, partial failures), debugging/tracing harder, data consistency challenges (eventual consistency), operational overhead (monitoring, logging, deployment), testing integration complex.
      typical_components:
        - API Gateway (routing, auth, rate limiting)
        - Service mesh (Istio, Linkerd)
        - Message broker (Kafka, RabbitMQ)
        - Service registry (Consul, Eureka)
        - Centralized logging (ELK)
        - Distributed tracing (Jaeger, Zipkin)
      when_to_use: Large applications with multiple teams, need independent scaling, varied domains, long-lived complex systems, high availability requirements.
      tech_examples:
        - Netflix OSS (Eureka, Hystrix, Zuul)
        - Amazon AWS (Lambda + API Gateway + SQS)
        - Uber (microservices on Go/Node)
        - Spotify (microservices with Python/Java)
        - Docker + Kubernetes
        - gRPC/protobuf for service comms
    - name: Event-Driven Architecture
      category: Distributed Systems
      description: Components communicate via events (state changes). Producers publish events; Consumers subscribe and react. Loose coupling, asynchronous, highly scalable.
      key_principles:
        - Events represent facts (what happened, not what to do)
        - Publish-subscribe or event streaming
        - Event sourcing (store events as source of truth)
        - Loose coupling (producers don't know consumers)
        - Asynchronous communication
        - Eventually consistent
      benefits: Loose coupling, scalability (can add consumers), resilience (message queues buffer failures), extensibility (new consumers without changing producers), real-time reaction.
      tradeoffs: Complexity of messaging infrastructure, debugging/observability harder (distributed traces), eventual consistency, event ordering challenges, message duplication.
      typical_components:
        - Event producers (publish events)
        - Event broker/message broker (Kafka, RabbitMQ)
        - Event consumers/processors
        - Event store (optional, for event sourcing)
        - Event schema registry (Avro, Protobuf)
      when_to_use: Real-time systems, data pipelines, IoT, distributed systems with loose coupling needed, systems needing audit trail (event sourcing), decoupling services.
      tech_examples:
        - Kafka (event streaming)
        - RabbitMQ (AMQP)
        - AWS EventBridge / SNS/SQS
        - Azure Event Hubs
        - Google Cloud Pub/Sub
        - Redis Streams
    - name: Layered Architecture (N-Tier)
      category: Structural
      description: Organizes system into horizontal layers (presentation, business logic, data access). Each layer depends only on layer directly below it. Classic enterprise architecture.
      key_principles:
        - Separation by technical concern (not business domain)
        - Layer dependencies only downward (presentation → business → data)
        - Each layer exposes interfaces to layer above
        - Reusable layers across applications
        - Can be deployed monolithically or distributed tiers
      benefits: Simple to understand, separation of concerns clear, testable layers, technology swapping per layer possible, widely understood.
      tradeoffs: Can become monolithic blob (all code in one deployable), single layer failure affects all, network overhead if tiers distributed, layer boundaries may blur over time.
      typical_components:
        - Presentation layer (UI, API endpoints)
        - Business Logic layer (services, domain models)
        - Data Access layer (repositories, DAOs)
        - Database layer (SQL/NoSQL)
      when_to_use: Traditional enterprise applications, CRUD-heavy apps, simple monoliths that may later split, teams familiar with layered approach.
      tech_examples:
        - 3-tier architecture (web server, app server, DB)
        - Java EE/Jakarta EE (Servlet → EJB → JDBC)
        - Spring (Controller → Service → Repository)
        - .NET (UI → BLL → DAL)
    - name: Hexagonal Architecture (Ports & Adapters)
      category: Structural
      description: Application core (business logic) is isolated from external concerns (UI, DB, external APIs) via ports (interfaces) and adapters (implementations). Also called Clean Architecture or Onion Architecture.
      key_principles:
        - Core domain at center (independent of frameworks)
        - Ports (interfaces) define required operations
        - Adapters implement ports for specific technologies
        - "Dependency rule: outer layers depend on inner layers"
        - Framework-agnostic core (testable in isolation)
      benefits: Testable core without infrastructure, technology-agnostic business logic, easy to swap adapters (e.g., MySQL → PostgreSQL), framework independence, clear boundaries.
      tradeoffs: More boilerplate/interfaces, may feel over-engineered for simple CRUD apps, learning curve, many small files.
      typical_components:
        - Core domain (entities, use cases, interfaces)
        - "Primary adapters (driving: UI, API, CLI)"
        - "Secondary adapters (driven: DB, external APIs, messaging)"
        - Ports (interfaces defining collaborations)
      when_to_use: Long-lived business applications, complex domain logic, need test isolation from infrastructure, framework-agnostic core desired.
      tech_examples:
        - Alistair Cockburn's Hexagonal Architecture
        - Robert C. Martin's Clean Architecture
        - Jeffrey Palermo's Onion Architecture
        - Spring Boot with repository interfaces
        - NestJS (dependency injection, modules)
    - name: CQRS (Command Query Responsibility Segregation)
      category: Structural
      description: Separate read (query) and write (command) operations. Commands modify state (write model); Queries read state (read model). May use separate databases/schemas.
      key_principles:
        - "Commands: mutate state, return result/void"
        - "Queries: read state, return DTO, no side effects"
        - Separate models (write model vs read model)
        - Read model optimized for queries (denormalized)
        - Write model enforces invariants and business rules
        - Eventual consistency between models
      benefits: Optimized models for each purpose (writes enforce rules, reads optimized for queries), scalability (read replicas), audit trail from commands, clear separation of concerns.
      tradeoffs: Complexity (two models to maintain), eventual consistency (not immediately consistent), increased infrastructure, may not be necessary for simple CRUD.
      typical_components:
        - "Command side: Command Handlers, Aggregate Roots, Domain Events"
        - "Query side: Query Handlers, Read Models/DTOs, Materialized Views"
        - Event Bus (sync/async)
        - Separate databases or schemas
      when_to_use: High-read vs write asymmetry, complex domain with business rules, need audit log of all changes, scalability demands separate read/write scaling.
      tech_examples:
        - EventStoreDB (event sourcing + CQRS)
        - Axon Framework (Java)
        - "MediatR (C#)"
        - NestJS CQRS module
        - Kafka + separate read DB (PostgreSQL read replica)
    - name: Serverless Architecture
      category: Cloud-Native
      description: Applications built using managed services and Functions-as-a-Service (FaaS). No server management; cloud provider handles scaling, availability, infrastructure.
      key_principles:
        - Functions are stateless and ephemeral (short-lived)
        - Event-driven execution (HTTP, queue, timer, stream)
        - Pay-per-use pricing model
        - Auto-scaling from zero to massive scale
        - Infrastructure managed by cloud provider
        - Composition of managed services (DB, storage, queues)
      benefits: No server management, automatic scaling, cost-effective for spiky workloads, faster time-to-market, built-in high availability.
      tradeoffs: Vendor lock-in (proprietary services), cold start latency, debugging/monitoring harder, execution time limits (max duration), local testing difficult, distributed transactions complex.
      typical_components:
        - FaaS functions (AWS Lambda, Azure Functions, Google Cloud Functions)
        - Managed services (DynamoDB, S3, API Gateway)
        - Event sources (HTTP, queues, streams, timers)
        - Infrastructure-as-Code (CDK, Terraform)
      when_to_use: Spiky/irregular workloads, APIs and webhooks, event processing (file upload, DB changes), IoT backends, rapid prototypes, microservices on FaaS.
      tech_examples:
        - AWS Lambda + API Gateway + DynamoDB
        - Azure Functions + Cosmos DB
        - Google Cloud Functions + Firestore
        - Netlify/Vercel Functions
        - Serverless Framework
        - AWS Step Functions (orchestration)
    - name: Service Mesh
      category: Infrastructure
      description: Dedicated infrastructure layer for service-to-service communication. Handles load balancing, retries, circuit breaking, observability, security (mTLS) transparently via sidecar proxies.
      key_principles:
        - Sidecar proxy per service (Envoy, Linkerd-proxy)
        - Control plane manages proxies (policy, configuration)
        - Data plane handles traffic (L7 routing)
        - Zero-trust security (mTLS between services)
        - Observability (metrics, logs, traces)
        - Traffic shifting (canary, blue-green)
      benefits: Consistent cross-cutting concerns (no code per service), security (mTLS auto), observability (unified telemetry), traffic management (A/B testing, canary), resilience (retries, circuit breakers).
      tradeoffs: Added complexity (deployment, ops), resource overhead (sidecars), learning curve, may be overkill for small deployments, latency added by proxy.
      typical_components:
        - Sidecar proxy (Envoy) per service instance
        - Control plane (Istio Pilot, Linkerd Controller)
        - Service registry (Kubernetes, Consul)
        - Ingress/Egress gateways
      when_to_use: Large microservices deployments (50+ services), need uniform security/observability, complex traffic routing, service-level policies enforced consistently.
      tech_examples:
        - Istio (most feature-rich)
        - Linkerd (lightweight, easy)
        - Consul Connect
        - AWS App Mesh
        - Kuma
        - NGINX Service Mesh