イベント駆動プログラミングの実装において、イベントやイベントループはしばしばプラットフォームから提供される(c.f. ウェブブラウザ).
一方でイベントハンドラの設計は規定されず実装者に一任される。イベント駆動プログラミングにはしばしば頻出するハンドラ設計パターンが存在する。
もっとも素朴なパターンは1つのイベントに1つの専用ハンドラを設定するパターンである。例えばClickイベントに対してonClickイベントハンドラ1つのみを登録する。ハンドラは対応するイベントが引数となることを前提としてイベントに対する全ての処理を記述する(≒ 同期的メッセージキュー)。
また1つのイベントに複数のハンドラを登録するパターンもある。その場合、2つの設計がありうる。
アクティビティベース
特定のイベントに応答して起こる個別の活動(アクティビティ)を記述するハンドラ。ハンドラは対応するイベントが引数となることを前提としてイベントに対する個別のアクティビティを記述する。例えばコンビニアプリを想定すると、客の入店に対し店内音声と店員挨拶の2アクティビティをおこなうとする。これを実装するためにonEnterToBellハンドラとonEnterToHelloハンドラを個別に用意し、両方をEnterイベントに登録する。1つのハンドラは特定のイベントとアクティビティに特化している。
ドメインベース
特定のドメインにおける全てのイベントを扱うハンドラ。全てのイベントを引数として受け付け、そのドメインが利用しないイベントを受け付けた場合は単純にスルーし、必要に応じて処理をおこなう。例えばコンビニアプリを想定すると、店内放送ハンドラは入店イベントと会計イベントを受け付けるが、入店イベントのみに対して音声を流す処理をおこなう。1つのハンドラは特定ドメインの更新に特化しており機能的に凝集している(関心の分離)。
Flux
Fluxアーキテクチャは1つのeventがドメインごとに分けられた複数のハンドラで処理されるパターンである。Fluxの用語では action:reducer=1:Nと言える。