Listing Vault SE322 · chapter 04 · Architecture Patterns

Chapter 04 — Architecture Patterns

Styles and patterns: layered, MVC, pipes and filters, client-server and broker, repository and blackboard, and event-driven architecture — with their costs, not just their benefits.

04chapter
—lists
—total items
04

Architecture Patterns

19 lists

Style Categories 5

CategoryMembers
Data-centeredRepository, Blackboard
Data-flowPipes and Filters (batch sequential)
DistributedClient-Server, Broker, Three-tier / n-tier
InteractiveModel-View-Controller
HierarchicalLayered, Main program and subroutine

A Pattern Is Documented As 4

  1. Problem
  2. Context
  3. Solution
  4. Consequences — the part that makes it a design tool, not a template

A Style Is 2

  1. A vocabulary of element and connector types
  2. Constraints on how they may be combined

Layered — Classic Four Layers 4

  1. Presentation
  2. Business
  3. Persistence
  4. Database

Layered — Benefits 3

  1. Portability
  2. Replaceability of a layer
  3. Separation of concerns

Layered — Costs 3

  1. Added latency
  2. Duplicated transformations between layers
  3. Pressure to bypass layers

Layered — Open vs Closed 2 + 1

  1. Closed layer — a request may only call the layer directly below
  2. Open layer — a request may skip it
  3. Sinkhole anti-pattern — most requests pass through layers that add no logic

MVC — The Three Parts 3

  1. Model — domain state; notifies observing views of change and knows no specific view
  2. View — presentation; observes the model
  3. Controller — interprets input and updates the model

MVC — Consequences 4

  1. Multiple views can share one model
  2. UI change is isolated from domain logic
  3. Interaction complexity increases
  4. Poor allocation gives fat controllers or anemic models

MVC — Variants 2

  1. MVP — Model-View-Presenter
  2. MVVM — Model-View-ViewModel

Pipes and Filters — Properties 4

  1. Filters are independent and stateless with respect to their neighbours
  2. Filters can be reused, reordered and run concurrently
  3. Throughput is limited by the slowest filter
  4. A single shared data format is what keeps filters recombinable

Pipes and Filters — Must Define 4

  1. Data formats
  2. Error propagation
  3. Backpressure
  4. Termination

Pipes and Filters — Poor Fit 2

  1. Shared state across filters
  2. Interactive workflows that go backwards

Broker — Responsibilities 4

  1. Register servers
  2. Locate a server for the client
  3. Forward the request
  4. Return results or exceptions

Distribution — What Networks Add 4

  1. Partial failure
  2. Latency
  3. Retries (make operations idempotent)
  4. Versioning

Repository vs Blackboard 2

RepositoryBlackboard
DataPassive shared data storeShared blackboard of partial solutions
ControlClients drive controlChanges to the data decide which agent runs next
PartsCentral data store + client componentsBlackboard + knowledge sources + controller
SuitsConsistent shared state, many tools on one modelProblems with no deterministic solution sequence
RiskBottleneck and coupling pointHard to predict, hard to debug

Event-Driven — Topologies 2

  1. Mediator — an orchestrator routes the event through a multi-step workflow
  2. Broker — consumers chain directly, simpler flows, no central coordinator

Event-Driven — Design For 4

  1. Idempotency
  2. Duplicate delivery
  3. Eventual consistency
  4. Failure handling

Event-Driven — Trade-offs 2

  1. Gains — decoupling, scalability, easy fan-out to new consumers
  2. Costs — ordering, debugging without a call stack (needs correlation IDs and tracing)