Compound Patterns

MVC decouples domain logic (Model) from presentation (View) via a control layer (Controller). The Model notifies Views of state changes through the Observer pattern, allowing multiple views to reflect the same data. The Controller uses the Strategy pattern to select appropriate business logic based on user input. Views often form a Composite tree for hierarchical UI construction. This separation enables independent development: designers refine Views, domain experts build Models, and developers wire Controllers. Changes to business logic don't require UI rewrites, and the same Model can power desktop, web, and mobile clients. MVC remains the backbone of web frameworks because it scales from small prototypes to large systems. Testability improves dramatically—you can unit-test Models and Controllers without rendering Views.

MVVM extends MVC by introducing ViewModel—a facade that exposes Model state in View-friendly terms and handles View commands. The breakthrough is two-way data binding: when you change an input, the ViewModel automatically syncs to the Model, and when the Model updates, Views refresh without imperative code. ViewModels encapsulate presentation logic (formatting, validation, visibility toggles) that doesn't belong in Models. They act as facades, simplifying Models for the View layer. User actions become Commands that the ViewModel executes, decoupling UI events from business logic. MVVM shines in rich UI applications (desktop, modern SPAs) where constant synchronization between user input and display is essential. Frameworks like Angular, Vue, and WPF handle the data binding machinery, so you focus on what changes, not how to push updates.

CQRS splits the application into two asymmetric paths: one for state-changing operations (commands) and one for reading state (queries). Unlike traditional CRUD, which uses the same Model for both reads and writes, CQRS recognizes they have different optimization needs—writes must be consistent and auditable, while reads must be fast and flexible. Commands are executed against a write model that enforces business rules. Each command generates events that are appended to an event log. Queries hit a separate, denormalized read model optimized for performance. An observer watches the event log and rebuilds read models asynchronously, creating eventual consistency. This pattern excels in event-driven systems where you need audit trails, distributed consistency, or support for multiple query indexes. The tradeoff is increased complexity: you manage two models and must handle eventual consistency.

Event Sourcing inverts the traditional database model. Instead of storing current state, you store a log of all state-changing events. The current state is derived by replaying events from the beginning. This provides a complete audit trail and enables temporal queries (what was the state at time T?). Each command produces one or more events that are immutable and append-only. The Memento pattern is implicit: events capture snapshots of state transitions. Observers (event handlers) subscribe to the event log and maintain materialized views or side effects. Recovery is trivial—replay events—and debugging is powerful because you have a record of every state change. Event Sourcing pairs naturally with CQRS, though they are independent. Complexity increases because you manage event versioning and eventual consistency. Not every system needs it, but it's invaluable for financial systems, auditing, and temporal analytics.

Circuit Breaker wraps calls to external services (APIs, databases, microservices) and monitors their success rate. When failures exceed a threshold, the circuit 'opens'—requests fail immediately without calling the remote service, giving it time to recover. After a timeout, the circuit enters 'half-open' state and tests a single request. If it succeeds, the circuit 'closes' and resumes normal operation. The State pattern is central: the circuit transitions between closed (normal), open (failing fast), and half-open (testing recovery). The Proxy pattern wraps the remote call, intercepting it to check circuit state. Observers watch metrics (latency, error rates) and trigger state transitions. Circuit Breaker is essential in microservices and distributed systems because it stops thundering-herd problems: one slow service doesn't drag down all callers. It works best paired with retries, timeouts, and fallbacks for resilient architectures.

Repository acts as a facade over data access logic, presenting collections as in-memory data structures (List, Set) rather than exposing SQL or API calls. It abstracts the persistence mechanism—swap SQL for NoSQL, REST API, or mock data, and the rest of the application stays unchanged. The Factory pattern appears when the repository creates domain objects from raw data (rows, JSON). Proxy pattern enables lazy loading: query results are wrapped in proxies that fetch related data on access. Together, these patterns isolate the application from persistence details, making testing trivial (mock the repository) and migrations painless. Repository is foundational in DDD and ORM-based architectures. It's less relevant in functional or query-oriented systems, but it remains the gold standard for object-oriented applications that value testability and separation of concerns.

Plugin Architecture lets third-party code extend an application without modifying its source. The core defines plugin interfaces (strategies); plugins implement these interfaces. A plugin loader (factory) discovers, validates, and instantiates plugins at startup or runtime. The core publishes events (observer) that plugins subscribe to and extend. Strategy pattern is obvious: plugins are alternative strategies injected at runtime. Factory pattern manages instantiation and dependency injection. Observer pattern allows plugins to hook into application lifecycle events (app-start, user-login, document-save) and intercede. This pattern powers IDEs (IntelliJ, VS Code), browsers (Chrome extensions), and gaming engines. The tradeoff is increased complexity: you must carefully design plugin interfaces, handle versioning, and manage security (sandboxing).

Middleware pipelines layer cross-cutting concerns (logging, authentication, compression, error handling) as decorators that wrap each other. A request flows through the chain: each middleware can inspect it, modify it, pass it to the next, and intercept the response. This separates concerns beautifully—add logging without touching auth code. The Decorator pattern is explicit: each middleware wraps the next middleware, adding behavior transparently. Chain-of-Responsibility is the execution model: a request passes through the chain until handled. Middleware can short-circuit the chain (e.g., reject authentication) or augment the response on the way back out. Middleware pipelines are ubiquitous in web frameworks (Express, Spring, Django) and are the primary way to organize cross-cutting concerns in modern applications. They're simpler than AOP and more flexible.

RAG Agents are LLM-powered systems that ground responses in retrieved knowledge rather than relying on parametric memory alone. The agent loops: (1) accept a user query, (2) retrieve relevant documents from a vector store (RAG), (3) decide what tools to invoke (web search, database query, calculator), (4) execute tools and feed results back to the LLM (ReAct pattern), (5) repeat until the LLM decides it has enough context to answer confidently. Memory management is critical: short-term context (conversation history), medium-term (retrieved documents), and long-term (vector embeddings). Guardrails ensure the agent doesn't hallucinate, invoke unauthorized tools, or answer outside its domain. The agent's reasoning is visible: it logs which documents were retrieved, which tools were called, and how it synthesized an answer. RAG Agents power customer support bots, research assistants, and enterprise question-answering systems. They're more reliable than pure LLMs because they cite sources and adapt to new information without retraining.

ML Feature Platforms unify the infrastructure for managing features (derived inputs), training models, and serving predictions. A feature store decouples feature computation from model code: define a feature once, reuse across training and serving. A model registry catalogs trained models with metadata (version, performance, lineage). A training pipeline orchestrates data prep, feature engineering, and model training. A serving pipeline encapsulates inference, feature lookup, and caching for low-latency predictions. Monitoring continuously checks model drift and data quality. These platforms standardize ML workflows and reduce friction: data scientists focus on feature engineering and modeling, engineers operationalize training and serving, and both trust the shared feature store as the source of truth. Without a platform, teams end up with skew: training uses different features than serving, leading to model degradation in production. ML Feature Platforms are complex but essential in organizations running 100+ models. They're powered by orchestration (Airflow, Kubeflow), databases (Snowflake, BigQuery), and specialized tools (Tecton, Databricks Feature Store).