In the world of software design, decoupling is a recurring goal. Systems built from loosely coupled components are more maintainable, testable, and scalable. But we still want to balance that with being easy to use in simple scenarios. Two design patterns that often work well together to achieve this are the Mediator and Command patterns. Though distinct in purpose, their combined usage can create a powerful messaging and orchestration mechanism in complex applications.
In this post, we’ll explore the theoretical foundations of each pattern, how they complement one another, common use cases, and the trade-offs of applying them together.
The Command Pattern: Decoupling Sender from Receiver
The Command pattern encapsulates a request as an object, thereby allowing users to create different requests, queue or log requests, and support durable operations. Within the command such details as how an entity is created or validated or persisted to a database can all be hidden from various clients (mobile app, web client, webapi endpoint).
Key Concepts:
- Command: An object that represents an action.
- Invoker: Triggers the command without knowing the logic.
- Receiver: The component that actually performs the action.
- Client: Creates the command and assigns the receiver.
Benefits:
- Encapsulation of behavior: Commands are discrete objects, often serializable or storable.
- Extensibility: New commands can be added without changing existing code.
The Mediator Pattern: Coordinating Component Interactions
The Mediator pattern defines an object that encapsulates how a set of objects interact. Instead of components referring to each other directly, they communicate through the mediator. This reduces the dependencies between communicating components. The client doesn’t need to know about the command handlers directly or how to instantiate them. It also gives a single point of entry for running shared services (like logging, validation, etc) within the facade of that central hub.
Key Concepts:
- Mediator: Central hub that routes communication.
- Colleagues: Components that communicate via the mediator.
Benefits:
- Reduces coupling between components.
- Simplifies communication logic, especially in complex object graphs.
- Centralizes behavior in one place for easier modifications.
Combining Mediator and Command Patterns
When used together, the Command pattern defines a request, while the Mediator handles the dispatch and orchestration of that request. This combination is especially prevalent in CQRS (Command Query Responsibility Segregation) architectures, WebApi-based services, and message-driven systems.
Conceptual Workflow:
- A client creates a Command object (e.g.,
CreateOrderCommand). - The Command is sent to the Mediator (e.g.,
Send(command)). - The Mediator locates the appropriate handler and invokes it.
- The handler performs the operation, possibly returning a result.
This separation of responsibilities allows commands to be purely declarative (they say what to do), while the mediator and handlers define how to do it.
Common Use Cases
- CQRS and Domain-Driven Design: Commands represent user intentions or domain actions; queries are handled separately for reads.
- WebApi Endpoints: Commands represent endpoint HttpRequests, the mediator runs the handler for that operation, and returns an HttpResponse.
- UI Interaction Handling: Commands map to user actions (e.g., button clicks), and the mediator orchestrates responses.
- Workflows and Orchestration: A mediator coordinates multiple steps or side-effects triggered by a single command.
- Plugin Architectures: Commands and handlers can be defined across module boundaries with minimal coupling.
Benefits of Using Mediator + Command
- Clean separation of concerns: Each part of the system (command, handler, mediator) has a well-defined responsibility.
- Improved testability: Commands and handlers are simple units to test in isolation.
- Pluggable behavior: New commands/handlers can be added without touching existing logic.
- Scalability of behavior: With pipeline behaviors or decorators, cross-cutting concerns (like logging, validation, authorization) can be added without modifying the core business logic.
- Reduced coupling: Callers don’t need to know how a request is processed or who processes it.
Drawbacks and Trade-offs
Despite its elegance, this pattern combination introduces some trade-offs:
- Indirection Overhead:
- It can become harder to trace behavior since logic is spread across commands, handlers, and the mediator.
- Verbosity:
- For simple operations, creating a command class, handler, and wiring may be overkill.
- Performance:
- Excessive use of dynamic dispatch or middleware pipelines can introduce latency.
- Debugging Complexity:
- Tools and developers must be equipped to follow indirect message flows, especially when pipelines or asynchronous processing are involved.
- Code Explosion:
- Each action becomes its own command-handler pair, leading to a large number of small files or types.
Conclusion
The Mediator and Command patterns are powerful tools when applied thoughtfully. They excel in complex applications requiring modularity, scalability, and a clear separation between intent and execution. That said, developers must weigh the architectural clarity they bring against the potential for over-engineering.
In simpler applications, these patterns may introduce unnecessary complexity. But in large-scale systems with evolving requirements and multiple interacting parts, the combination of Mediator and Command can be a cornerstone of robust, maintainable design.
DarthPedro's Blog 