Notification Service

Channels hard-coded at every call site

Sending a notification means calling each channel directly. Add SMS or Push and every call site needs editing — and nobody checks what the user actually wants.

function shipOrder(order) {
  sendEmail(order.user, msg);
  sendSMS(order.user, msg);
  // ← new channel? edit here too…
  // ← user opted out of SMS? too bad.
}

Event triggers a service; channels are swappable strategies

An Observer subscribes the service to a domain event. Each channel is a Strategy behind send(msg). A Template Method defines the skeleton: build → deliver → log.

on('OrderShipped', e => notify(user, e));

class NotificationService {
  channels = [];              // Strategy list
  register(ch) { this.channels.push(ch); }

  notify(user, evt) {
    const msg = this.build(evt);   // Template Method
    this.channels
      .filter(c => user.prefs[c.name])
      .forEach(c => c.send(msg));  // each = Strategy
  }
}

Trigger the event — only preferred channels fire

The event fans out through the service to the user's enabled channels only. Register a brand-new channel at runtime — the service core never changes.

Tip: click a channel to toggle the user's preference, then trigger again.

Decoupled by event, chosen by preference

• Decouples trigger from delivery: callers just raise an event; they never touch channels.
• Open/Closed: register a new channel (Slack, webhook…) without editing the service core.
• Preferences respected: each channel is filtered by user.prefs before it sends.
• One send skeleton: build → deliver → log/retry is defined once, shared by every channel.
• Caution: real delivery is async — plan for retries, rate limits, and per-channel failures.