Design the object model and public APIs for an in-process event bus: a library other modules inside one application use to publish typed events and to subscribe handlers to them, so producers and consumers never hold direct references to each other.

Operating context. One process, many modules on the same heap. A publisher calls publish(event); every handler registered for that event's type is invoked. Handlers register with subscribe(EventType, handler) and get back a token they can later use to unsubscribe. Some callers want synchronous, in-order delivery on the publishing thread; others want the publish call to return immediately and have handlers run on a background worker. The type registry is small (dozens of event types), but a hot event type can have hundreds of handlers and be published thousands of times per second. Handlers are ordinary objects that may outlive or predecease the bus, and a handler that throws must not stop its siblings from running.

Out of scope. Cross-process or networked messaging, durable persistence and replay, an external broker, delivery guarantees across a restart, and the concrete business logic inside any handler (assume handlers are given).

What to produce. The class hierarchy (the bus, subscriptions/tokens, the event-type key, the dispatch strategy seam), the public API each type exposes, and the lifecycle of a subscription (subscribed -> delivering -> unsubscribed / collected). Be explicit about: how events route to handlers by type, how synchronous and asynchronous dispatch are selected without branching all over the bus, how per-handler ordering and error isolation are guaranteed, how unsubscribe is made safe during an in-flight publish, and how a handler that is garbage-collected does not leak or get called.