In-process event bus and domain events

An in-process event bus lets one part of a program announce that something happened while other parts react to it, and neither side knows the other: publishers and subscribers know only the bus and the event types. Domain events are the announcements a domain model makes, named in the past tense, such as OrderPaid. When an order is paid, an invoice, loyalty points and a text message must follow. With a bus, the order publishes one OrderPaid event and three handlers subscribe to it, so a fourth reaction is a new handler and no change to the order. Martin Fowler describes the same shape as an Event Aggregator, which channels the events of many objects through one object that clients subscribe to.

The examples ran on Python 3.14.8, and one on Node.js 24.21.0; all but the Node.js one also run in your browser.

Publishers, subscribers and one bus between them

Without a bus, Order.pay() calls the invoice service, the loyalty service and the text-message sender itself. Every new reaction edits the order’s code, every test of the order needs fakes for all three, and a failure in the message sender can stop a payment. With a bus, the order depends on one small object. Fowler’s Domain Event pattern describes an event as the memory of something interesting that affects the domain, so events are facts: immutable, and named for what already happened.

The program builds a bus of ten lines, publishes two OrderPaid events and lets one handler unsubscribe between them:

"""An in-process event bus: an order publishes OrderPaid, and three handlers react without the order knowing any of
them. The handlers only print what real ones would do."""
from collections import defaultdict
from dataclasses import dataclass


@dataclass(frozen=True)
class OrderPaid:  # a domain event: named in the past tense, and never changed once raised
    order_id: str
    amount_paise: int
    customer: str


class EventBus:
    def __init__(self):
        self.handlers = defaultdict(list)  # event type -> handlers, in the order they subscribed

    def subscribe(self, event_type, handler):
        self.handlers[event_type].append(handler)
        return lambda: self.handlers[event_type].remove(handler)  # call it to unsubscribe

    def publish(self, event):
        for handler in tuple(self.handlers[type(event)]):
            handler(event)


class Order:
    def __init__(self, order_id, amount_paise, customer, bus):
        self.order_id, self.amount_paise, self.customer, self.bus = order_id, amount_paise, customer, bus
        self.status = "new"

    def pay(self):
        self.status = "paid"
        self.bus.publish(OrderPaid(self.order_id, self.amount_paise, self.customer))


def issue_invoice(event):
    print(f"  invoice: issued for {event.order_id}, {event.amount_paise / 100:.2f} rupees")


def award_points(event):
    print(f"  loyalty: {event.amount_paise // 10_000} points to {event.customer}")  # 1 point per 100 rupees


def send_sms(event):
    print(f"  sms: {event.customer}, your payment for {event.order_id} is received")


bus = EventBus()
bus.subscribe(OrderPaid, issue_invoice)
bus.subscribe(OrderPaid, award_points)
stop_sms = bus.subscribe(OrderPaid, send_sms)

print("A-1042 paid")
Order("A-1042", 125_000, "Asha", bus).pay()
stop_sms()  # Asha turned text messages off
print("A-1043 paid")
Order("A-1043", 49_900, "Asha", bus).pay()

A-1042 paid
  invoice: issued for A-1042, 1250.00 rupees
  loyalty: 12 points to Asha
  sms: Asha, your payment for A-1042 is received
A-1043 paid
  invoice: issued for A-1043, 499.00 rupees
  loyalty: 4 points to Asha

The order called publish() and nothing else. The handlers ran in the order they subscribed, and after stop_sms() the second payment produced no text message. An in-process event bus is this small, which is both its appeal and its limit: it runs inside one process, during the publisher’s own call, and stores nothing.

A bus that real code can rely on needs five more decisions, and each has a name:

• Dispatch after commit holds domain events until the transaction commits, so a payment that rolls back is never announced.
• The snapshot rule stops a handler that unsubscribes during a publish from making the bus skip another handler.
• Failure isolation lets every handler run when one of them fails, and tells the publisher about each failure.
• Asynchronous dispatch spares the publisher the wait, but it changes what order and failure mean.
• Durability is what an in-process bus lacks: waiting events die with the process, and redelivery needs idempotent handlers.

A failure drill: the handler that unsubscribed while the bus was publishing Pro: opens with a Pro, Premium or Ultimate pass