api: YAML JSON TOON Database
version: 1.0.0
format: json
dataset:
  id: 39
  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."
  summary: "System-level architectural patterns: MVC, MVVM, microservices, event-driven, layered, hexagonal and CQRS, each with category, description, key principles, benefits, trade-offs, typical components, when to use it and technology examples."
  use_when[2]: You are choosing or reviewing the overall architecture of a system.,You need the main trade-offs of a pattern.
  caveats[2]: "Architectural patterns come with operational cost; microservices, for example, add distributed-system complexity.","Real systems mix patterns, and the right one depends on team size, scale and change rate."
  related[4]: serverless-patterns,behavioral-design-patterns,concurrency-design-patterns,database-comparison
  category: Design Patterns
  category_slug: design-patterns
  tags: "design-patterns,architectural,mvc,microservices,event-driven,serverless"
  view_count: 0
  created_at: 1777673262
  updated_at: 1777673262
  entry_count: 9
  fields[9]{section,field,type,example}:
    patterns,name,string,MVC (Model-View-Controller)
    patterns,category,string,Component-Based
    patterns,description,string,"Separates application into three components: Mo…"
    patterns,key_principles,array,"[5 items]"
    patterns,benefits,string,"Modular code structure, testability (test model…"
    patterns,tradeoffs,string,Controller can become God object (too much logi…
    patterns,typical_components,array,"[3 items]"
    patterns,when_to_use,string,"Applications with rich UI requiring separation,…"
    patterns,tech_examples,array,"[6 items]"
data:
  patterns[9]:
    - 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[5]: "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[3]: "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[6]: 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[5]: 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[4]: 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[6]: 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[6]: 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[6]: "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[6]: "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[6]: "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[5]: 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[6]: 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[5]: 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[4]: "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[4]: "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[5]: 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[4]: "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[5]: 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[6]: "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[4]: "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[5]: 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[6]: 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[4]: "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[6]: 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[6]: "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[4]: 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[6]: Istio (most feature-rich),"Linkerd (lightweight, easy)",Consul Connect,AWS App Mesh,Kuma,NGINX Service Mesh