Design the object model and core APIs for an in-process notification service that other parts of an application call to fan a single event out to a user's chosen delivery channels (email, SMS, push). The service owns who is interested in an event, which channels each recipient wants, how the message is rendered per channel, and how a failed send is retried; the callers merely publish an event and read back a delivery result.

Operating context. One application process. A domain event (for example, "order shipped" or "password changed") is published with a typed payload. For each event type there is a set of subscribers; a subscriber resolves to one recipient plus that recipient's channel preferences and opt-outs. Each enabled channel renders the payload through a per-channel template into a concrete message and hands it to a channel-specific sender. A send may fail transiently, so a failed attempt is handed to a retry policy that decides whether and when to try again. New event types, new channels, and new template formats are added often, so the design must absorb them without editing the publish path. Everything runs on one process; there is no external queue or database in v1.

Out of scope. The actual email/SMS/push provider SDKs and their network calls (stub the senders), durable persistence of preferences or delivery logs, a distributed message broker or cross-process fan-out, batching/throttling at provider level, and the HTTP/RPC surface around the service. Design the in-process object model and its APIs, not the infrastructure.

What to produce. The class hierarchy (entities and value objects such as Event, Recipient, Subscription, Channel, Message, Template, and the service itself), the public API each class exposes, and the state transitions for a single delivery attempt (for example queued, sending, delivered, failed, retrying, dead-lettered). Be explicit about: how subscribers register and are notified when an event fires (observer), how a channel's rendering-and-sending behavior is selected and swapped (strategy), how per-recipient preferences and opt-outs suppress channels, how templates are chosen per event-type and channel, where the retry hook lives, and how a brand-new channel is added without touching the publish path or existing channels.