Event Aggregator Pattern in C#: Decoupled Messaging

Lesson 107 decoupled a publisher from its subscribers. It still needed a direct reference to raise its own event. This lesson removes even that.

Lesson 107's OrderService was a genuine win: it raised OrderPlaced and had zero references to InventoryUpdater or OrderConfirmationEmailer. But look closely at what was still required for that to work — a composition root that held a direct reference to orderService itself, in order to write orderService.OrderPlaced += inventoryUpdater.HandleOrderPlaced;. Every subscriber, and the code doing the wiring, still needed to know OrderService specifically exists, by type, in order to reach its event.

Now picture a larger application: an analytics module fifteen files away from OrderService, in a completely different part of the codebase, owned by a different team, that also wants to react to orders being placed. Does it take a constructor dependency on OrderService just to reach one event? Does every module that ever wants to react to anything end up needing a reference to every publisher in the system? At small scale this is fine. At the scale of a real application with dozens of publishers and dozens of subscribers scattered across unrelated features, direct event subscription — even lesson 107's decoupled version — still doesn't scale. This lesson introduces the tool that fixes it: an event aggregator.

What Is It?

The Simple Explanation

An event aggregator is a single, shared, injectable object that sits in the middle of a publish/subscribe relationship. Instead of Component A holding a reference to Component B in order to subscribe to B's event, both A and B hold a reference to the same third object — the aggregator. A publishes to the aggregator; B subscribes through the aggregator. Neither one ever needs to know the other's type, or that the other exists at all.

The Technical Definition

An event aggregator (sometimes called an in-process message bus — a name worth being careful with, covered under Common Confusion) is a service exposing two generic operations: Publish<TEvent>(TEvent evt), which broadcasts an event-data object of a given type to everyone currently subscribed to that type, and Subscribe<TEvent>(Action<TEvent> handler), which registers a handler to be called whenever an event of that type is published. Internally, the aggregator maintains its own mapping from event type to a list of subscribed handlers — it is, in effect, a general-purpose, reusable version of the single OrderPlaced event lesson 107 built by hand, generalized to handle any number of event types without a dedicated event declaration for each one.

Why Does It Exist?

The Problem — Direct Subscription Doesn't Scale to Many-to-Many

Lesson 107 decoupled what happens after an event fires from the publisher raising it. But it left one coupling in place: to subscribe to OrderService.OrderPlaced at all, you need a compile-time reference to the OrderService type — an assembly reference, a using, a constructor parameter somewhere. In a small application with a handful of publishers, that's a non-issue. In a real application with dozens of independent features — orders, inventory, analytics, notifications, loyalty, fraud detection, audit logging — each one potentially caring about events raised by several of the others, this breaks down in three concrete ways:

• Every subscriber needs a reference to every publisher it cares about. An analytics module that wants to react to order placement, inventory changes, and login events ends up depending on OrderService, InventoryService, and AuthService directly — exactly the kind of tangled, many-to-many dependency graph event-driven design was supposed to prevent in the first place.
• Adding a new publisher-to-subscriber connection means both sides — or at minimum the composition root — must know both types. A brand-new, unrelated module can't simply announce "I care about orders" without someone wiring it directly to OrderService.
• The composition root becomes a single, enormous file of wiring — every publisher-subscriber pair in the entire application, hand-connected, one line at a time, growing without bound as the application grows.

The Solution — One Shared Hub, Known to Everyone, Coupling No One to Anyone

An event aggregator breaks the direct A-knows-about-B relationship entirely. Every publisher and every subscriber depends on exactly one thing: the aggregator's interface. A brand-new analytics module can subscribe to OrderShipped the moment it's written, with no changes anywhere else in the codebase — not to OrderService, not to the composition root, not to any other subscriber. The aggregator is the only shared dependency, and it's a genuinely generic, reusable piece of infrastructure — write it once, and it serves every publish/subscribe relationship in the application, for any event type.

Big Picture

Analytics module
  needs: reference to OrderService
  needs: reference to InventoryService
  needs: reference to AuthService
  (couples to every publisher it cares about)

Analytics module
  needs: IEventAggregator (only)
  subscribes to: OrderShipped, StockLow, UserLoggedIn
  (couples to ONE shared abstraction, not to any publisher)

How It Works

public interface IEventAggregator
{
    void Publish<TEvent>(TEvent evt);
    void Subscribe<TEvent>(Action<TEvent> handler);
}

private readonly Dictionary<Type, List<Delegate>> _subscribers = new();

public void Subscribe<TEvent>(Action<TEvent> handler)
{
    var key = typeof(TEvent);
    if (!_subscribers.TryGetValue(key, out var list))
        _subscribers[key] = list = new List<Delegate>();
    list.Add(handler);
}

public void Publish<TEvent>(TEvent evt)
{
    if (!_subscribers.TryGetValue(typeof(TEvent), out var list)) return;
    foreach (var handler in list.ToArray()) // copy — see Under the Hood
        ((Action<TEvent>)handler).Invoke(evt);
}

Simple Example

using System;
using System.Collections.Generic;

public interface IEventAggregator
{
    void Publish<TEvent>(TEvent evt);
    void Subscribe<TEvent>(Action<TEvent> handler);
}

public class EventAggregator : IEventAggregator
{
    private readonly Dictionary<Type, List<Delegate>> _subscribers = new();

    public void Subscribe<TEvent>(Action<TEvent> handler)
    {
        var key = typeof(TEvent);
        if (!_subscribers.TryGetValue(key, out var list))
            _subscribers[key] = list = new List<Delegate>();
        list.Add(handler);
    }

    public void Publish<TEvent>(TEvent evt)
    {
        if (!_subscribers.TryGetValue(typeof(TEvent), out var list)) return;
        foreach (var handler in list.ToArray())
            ((Action<TEvent>)handler).Invoke(evt);
    }
}

public record UserSignedUp(string Email);

class Program
{
    static void Main()
    {
        IEventAggregator bus = new EventAggregator();

        // Two unrelated subscribers, neither knowing the other exists
        bus.Subscribe<UserSignedUp>(e => Console.WriteLine($"[Welcome Email] Sending to {e.Email}"));
        bus.Subscribe<UserSignedUp>(e => Console.WriteLine($"[Analytics] Recorded signup for {e.Email}"));

        bus.Publish(new UserSignedUp("sam@example.com"));
        // [Welcome Email] Sending to sam@example.com
        // [Analytics] Recorded signup for sam@example.com
    }
}

Code → Meaning → Result: Whatever code calls bus.Publish(new UserSignedUp(...)) has no idea a welcome-email handler or an analytics handler exists. Both subscribers found out about UserSignedUp purely by subscribing to the type, through the shared bus — no direct reference to whoever eventually publishes it.

Real-World Example — Order Fulfillment, Fully Decoupled

Here is lesson 107's order-placement scenario, rebuilt with an aggregator. OrderFulfillmentService, AnalyticsModule, and NotificationModule are three completely independent classes, in three imagined completely independent parts of a codebase — none of them reference each other, or even know the other two exist.

using System;

// ─── Event, shared only as a plain data type ───
public record OrderShipped(int OrderId, string TrackingNumber, decimal OrderTotal);

// ─── Publisher — order-fulfillment module. Knows only IEventAggregator. ───
public class OrderFulfillmentService
{
    private readonly IEventAggregator _bus;
    public OrderFulfillmentService(IEventAggregator bus) => _bus = bus;

    public void ShipOrder(int orderId, decimal orderTotal)
    {
        var trackingNumber = $"TRK-{orderId:D6}";
        // ... actual shipping logic here ...
        _bus.Publish(new OrderShipped(orderId, trackingNumber, orderTotal));
    }
}

// ─── Subscriber 1 — analytics module. Never heard of OrderFulfillmentService. ───
public class AnalyticsModule
{
    public AnalyticsModule(IEventAggregator bus)
        => bus.Subscribe<OrderShipped>(e =>
            Console.WriteLine($"  [Analytics] Recorded ${e.OrderTotal:N2} shipment for order #{e.OrderId}"));
}

// ─── Subscriber 2 — notification module. Never heard of AnalyticsModule either. ───
public class NotificationModule
{
    public NotificationModule(IEventAggregator bus)
        => bus.Subscribe<OrderShipped>(e =>
            Console.WriteLine($"  [Notify] Order #{e.OrderId} shipped — tracking {e.TrackingNumber}"));
}

// ─── Composition root — the only place that wires anything together ───
class Program
{
    static void Main()
    {
        IEventAggregator bus = new EventAggregator();

        _ = new AnalyticsModule(bus);
        _ = new NotificationModule(bus);
        var fulfillment = new OrderFulfillmentService(bus);

        fulfillment.ShipOrder(orderId: 2002, orderTotal: 89.99m);

        //   [Analytics] Recorded $89.99 shipment for order #2002
        //   [Notify] Order #2002 shipped — tracking TRK-002002
    }
}

Compare this to lesson 107's composition root, which had to write orderService.OrderPlaced += inventoryUpdater.HandleOrderPlaced; — a line that named both types explicitly. Here, the composition root constructs each module with the same shared bus and nothing more; no line of wiring code names both a publisher and a subscriber together. A brand-new FraudDetectionModule could be added tomorrow with a constructor that does bus.Subscribe<OrderShipped>(...), and neither OrderFulfillmentService nor any existing subscriber would need a single line changed.

Analogy

Under the Hood

An event aggregator is not new machinery at the CLR level — it's ordinary generics, an ordinary dictionary, and ordinary delegate invocation, arranged as a piece of shared infrastructure. A few implementation details are worth being deliberate about:

• Type identity is the routing key. typeof(TEvent) is what connects a Publish<OrderShipped> call to every Subscribe<OrderShipped> handler — there's no string matching, no reflection over method names, just a dictionary lookup keyed by the CLR Type object.
• Copy the handler list before iterating. The .ToArray() call in Publish matters for the same reason lesson 106 emphasized raising events via a local copy: if a handler subscribes or unsubscribes from within another handler that's currently running, mutating the live list mid-iteration would throw or produce inconsistent behavior. Iterating a snapshot avoids that.
• Same synchronous, in-process reality as lesson 107. Just like a plain event, Publish as shown here calls every handler synchronously, on the calling thread, in subscription order, before returning. An event aggregator is a routing mechanism, not a threading or queueing mechanism — it doesn't make anything asynchronous by itself. A production-grade aggregator built for a multi-threaded application would additionally need locking around the subscriber dictionary itself, exactly as lesson 191 covered for custom event accessors.
• Lifetime matters, exactly as it did for events. An aggregator that lives for the whole application (typically registered as a singleton in a dependency injection container) holds a reference to every handler ever subscribed to it. A subscriber that's shorter-lived than the aggregator and never unsubscribes reproduces the exact lapsed listener leak from lesson 191 — the aggregator doesn't remove this concern, it just moves the strong-reference chain one hop further, from publisher-holds-subscriber to aggregator-holds-subscriber.

Common Confusion

1. "Message bus" sounds like a message queue — inside one process, it isn't

The term "message bus" is used for this in-process pattern, but it is a completely different thing from the message brokers (RabbitMQ, Kafka, Azure Service Bus) that lesson 107 explicitly set aside for a later, distributed-systems topic. The EventAggregator in this lesson lives entirely inside one process's memory, has no durability (a published event that nobody happened to be subscribed to at that instant is simply gone — there's no "replay it later"), and involves no network hop whatsoever. If you hear "event aggregator" or "in-process message bus" in a job posting or a codebase, assume this lesson's pattern unless the context specifically says otherwise; if you hear "message queue," "broker," or a specific product name (Kafka, RabbitMQ, SQS), that's the different, later topic.

2. "An event aggregator replaces the event keyword everywhere" — no, it's a different tool for a different scale

A class that has exactly one well-known set of subscribers — a UI control's Click event, a domain object's own StatusChanged event — is still perfectly well served by a plain event, exactly as lessons 105–106 taught. An aggregator earns its complexity specifically when the number of independent, unrelated subscriber modules grows large enough that direct references between them become the actual maintenance burden. Reaching for an aggregator for a single, simple, two-party notification is unnecessary indirection.

Common Mistakes

Mistake 1 — Treating the aggregator as durable or asynchronous by default

Publishing an event and assuming a subscriber that registers itself moments later will still somehow receive it, or assuming Publish returns immediately while handlers run "in the background."

Remember it's synchronous and has zero memory of past events by default — a subscriber must be registered before Publish is called for that specific event to receive it, exactly like a plain event from lesson 105.

Mistake 2 — Forgetting to unsubscribe from a singleton-scoped aggregator

A short-lived object subscribes in its constructor and is never seen again — exactly the lapsed listener leak from lesson 191, just via the aggregator's internal dictionary instead of a class's own event field.

Design subscriptions with the same lifetime discipline as any event subscription: unsubscribe explicitly when the subscriber's own lifetime ends, or design the aggregator's subscription API to return an IDisposable "subscription token" that unsubscribes on Dispose() — a common refinement of the simple version shown here.

Mistake 3 — Routing every single call in an application through the aggregator "for consistency"

Using Publish/Subscribe even for a simple, direct, two-party interaction that a plain method call or a lesson-107-style dedicated event would express far more clearly.

Reach for an aggregator specifically for genuinely decoupled, many-to-many, cross-module notifications. A direct call remains simpler to read, simpler to debug (a normal call stack, not a type-keyed dictionary lookup), and appropriate whenever the relationship really is just two specific parties talking to each other.

When Should I Use It?

• When multiple, unrelated modules across a growing application need to react to the same facts, and you don't want every one of them to depend directly on whichever module happens to raise them.
• When you expect new publishers and new subscribers to be added independently over time, by different people or teams, without coordinating changes to a shared composition root.
• Skip it for a simple, stable, two-party relationship — a plain event (lessons 105–106) is simpler, more discoverable (an IDE can find every subscriber of a specific event with "Find References"; a type-keyed aggregator generally cannot), and appropriate when there's exactly one well-known publisher and a small, known set of subscribers.
• Skip it, too, for cross-service or cross-process communication — that remains the message-broker territory lesson 107 deliberately left for later; an in-process aggregator has no answer for a subscriber that's temporarily offline or a message that must survive a crash.

Mental Model

Key Takeaway

Check Your Understanding

You've seen how an event aggregator removes the last direct coupling that lesson 107's event-driven design still had. Let's confirm the details.

You've now taken event-driven design as far as it goes in-process — from a raw multicast delegate, through the standard pattern, through decoupled publishers, to a fully shared aggregator where no two modules need to know each other exist. Next: a completely different kind of code reuse — extension methods, the mechanism behind every LINQ call you've ever written.