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."
  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
data:
  patterns
    [9]{name,category,description,key_principles,benefits,tradeoffs,typical_components,when_to_use,tech_examples}:
      "MVC (Model-View-Controller)",Component-Based,"Separates application into three components: Model (data/business logic), View (UI presentation), Controller (input handling/orchestration). Promotes separation of concerns.",["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"],"Modular code structure, testability (test model/controller without UI), parallel development (frontend/backend), reusable models and views.","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.",["Model classes (data, validation, business rules)","View templates\/UI components","Controller\/Router (handles requests, updates model)"],"Applications with rich UI requiring separation, web frameworks (Rails, Django, Spring MVC), desktop apps, team-based development where roles are split.",["Ruby on Rails (MVC)","Django (MVC-like, MVT)","Spring MVC (Java)","ASP.NET MVC","Backbone.js (JS MVC)","Angular (MVVM variant)"]
      "MVVM (Model-View-ViewModel)",Component-Based,"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.",["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)"],"Excellent testability (ViewModel unit tests), designer-developer collaboration (designers work on XAML, devs on ViewModel), clean separation, reactive programming friendly.","Data binding can be opaque (hard to debug), memory leaks from event handlers, overkill for simple UIs, learning curve for binding syntax.",["Model (data layer)","View (XAML\/HTML template)","ViewModel (bindable properties, commands)","Data binding engine (framework-provided)"],"Applications with rich data binding (WPF, UWP, Xamarin, SwiftUI, Jetpack Compose), reactive UIs, teams with designer/developer split.",["WPF (Windows Presentation Foundation)","Xamarin \/ .NET MAUI","SwiftUI (Apple)","Jetpack Compose (Android)","Vue.js (Vuex\/Pinia inspired by MVVM)","Knockout.js"]
      "Microservices Architecture","Distributed Systems","Application as collection of small, independent services. Each service owns its data, runs in its own process, communicates via HTTP/gRPC/messaging. Independently deployable.",["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)"],"Independent scaling per service, team autonomy, tech stack flexibility, fault isolation (one service failure doesn't crash all), easier to understand codebase per service.","Complex distributed system (network latency, partial failures), debugging/tracing harder, data consistency challenges (eventual consistency), operational overhead (monitoring, logging, deployment), testing integration complex.",["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)"],"Large applications with multiple teams, need independent scaling, varied domains, long-lived complex systems, high availability requirements.",["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"]
      "Event-Driven Architecture","Distributed Systems","Components communicate via events (state changes). Producers publish events; Consumers subscribe and react. Loose coupling, asynchronous, highly scalable.",["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"],"Loose coupling, scalability (can add consumers), resilience (message queues buffer failures), extensibility (new consumers without changing producers), real-time reaction.","Complexity of messaging infrastructure, debugging/observability harder (distributed traces), eventual consistency, event ordering challenges, message duplication.",["Event producers (publish events)","Event broker\/message broker (Kafka, RabbitMQ)","Event consumers\/processors","Event store (optional, for event sourcing)","Event schema registry (Avro, Protobuf)"],"Real-time systems, data pipelines, IoT, distributed systems with loose coupling needed, systems needing audit trail (event sourcing), decoupling services.",["Kafka (event streaming)","RabbitMQ (AMQP)","AWS EventBridge \/ SNS\/SQS","Azure Event Hubs","Google Cloud Pub\/Sub","Redis Streams"]
      "Layered Architecture (N-Tier)",Structural,"Organizes system into horizontal layers (presentation, business logic, data access). Each layer depends only on layer directly below it. Classic enterprise architecture.",["Separation by technical concern (not business domain)","Layer dependencies only downward (presentation \u2192 business \u2192 data)","Each layer exposes interfaces to layer above","Reusable layers across applications","Can be deployed monolithically or distributed tiers"],"Simple to understand, separation of concerns clear, testable layers, technology swapping per layer possible, widely understood.","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.",["Presentation layer (UI, API endpoints)","Business Logic layer (services, domain models)","Data Access layer (repositories, DAOs)","Database layer (SQL\/NoSQL)"],"Traditional enterprise applications, CRUD-heavy apps, simple monoliths that may later split, teams familiar with layered approach.",["3-tier architecture (web server, app server, DB)","Java EE\/Jakarta EE (Servlet \u2192 EJB \u2192 JDBC)","Spring (Controller \u2192 Service \u2192 Repository)",".NET (UI \u2192 BLL \u2192 DAL)"]
      "Hexagonal Architecture (Ports & Adapters)",Structural,"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.",["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)"],"Testable core without infrastructure, technology-agnostic business logic, easy to swap adapters (e.g., MySQL → PostgreSQL), framework independence, clear boundaries.","More boilerplate/interfaces, may feel over-engineered for simple CRUD apps, learning curve, many small files.",["Core domain (entities, use cases, interfaces)","Primary adapters (driving: UI, API, CLI)","Secondary adapters (driven: DB, external APIs, messaging)","Ports (interfaces defining collaborations)"],"Long-lived business applications, complex domain logic, need test isolation from infrastructure, framework-agnostic core desired.",["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)"]
      "CQRS (Command Query Responsibility Segregation)",Structural,"Separate read (query) and write (command) operations. Commands modify state (write model); Queries read state (read model). May use separate databases/schemas.",["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"],"Optimized models for each purpose (writes enforce rules, reads optimized for queries), scalability (read replicas), audit trail from commands, clear separation of concerns.","Complexity (two models to maintain), eventual consistency (not immediately consistent), increased infrastructure, may not be necessary for simple CRUD.",["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"],"High-read vs write asymmetry, complex domain with business rules, need audit log of all changes, scalability demands separate read/write scaling.",["EventStoreDB (event sourcing + CQRS)","Axon Framework (Java)","MediatR (C#)","NestJS CQRS module","Kafka + separate read DB (PostgreSQL read replica)"]
      "Serverless Architecture",Cloud-Native,"Applications built using managed services and Functions-as-a-Service (FaaS). No server management; cloud provider handles scaling, availability, infrastructure.",["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)"],"No server management, automatic scaling, cost-effective for spiky workloads, faster time-to-market, built-in high availability.","Vendor lock-in (proprietary services), cold start latency, debugging/monitoring harder, execution time limits (max duration), local testing difficult, distributed transactions complex.",["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)"],"Spiky/irregular workloads, APIs and webhooks, event processing (file upload, DB changes), IoT backends, rapid prototypes, microservices on FaaS.",["AWS Lambda + API Gateway + DynamoDB","Azure Functions + Cosmos DB","Google Cloud Functions + Firestore","Netlify\/Vercel Functions","Serverless Framework","AWS Step Functions (orchestration)"]
      "Service Mesh",Infrastructure,"Dedicated infrastructure layer for service-to-service communication. Handles load balancing, retries, circuit breaking, observability, security (mTLS) transparently via sidecar proxies.",["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)"],"Consistent cross-cutting concerns (no code per service), security (mTLS auto), observability (unified telemetry), traffic management (A/B testing, canary), resilience (retries, circuit breakers).","Added complexity (deployment, ops), resource overhead (sidecars), learning curve, may be overkill for small deployments, latency added by proxy.",["Sidecar proxy (Envoy) per service instance","Control plane (Istio Pilot, Linkerd Controller)","Service registry (Kubernetes, Consul)","Ingress\/Egress gateways"],"Large microservices deployments (50+ services), need uniform security/observability, complex traffic routing, service-level policies enforced consistently.",["Istio (most feature-rich)","Linkerd (lightweight, easy)","Consul Connect","AWS App Mesh","Kuma","NGINX Service Mesh"]