Azure Service Bus主题触发函数：EventHandler与EventProcessor命名规范抉择

核心结论：优先使用EventHandler命名你的Service Bus Topic Trigger Azure Function #

你的场景中，每个订阅对应的Function只负责响应特定事件并执行单一业务动作（发送通知），EventHandler的语义更贴合这种“事件触发-单一响应”的职责定位；而EventProcessor通常对应更复杂的批量处理、多阶段加工场景，用在这里会显得语义过重。

两者的语义区别 #

• EventHandler：聚焦于单一事件的响应与特定动作执行，完全匹配Azure Function“单一职责”的设计原则。比如UserCreatedEventHandler，一看就知道是专门处理UserCreatedEvent、完成发送创建通知的任务，职责清晰无歧义。
• EventProcessor：多用于批量事件处理、多步骤数据加工，或需要维护处理状态的场景（比如从Event Hub拉取批量事件做聚合、格式转换后再输出）。你的场景里每个函数只做发送通知这一件事，用Processor会偏离语义。

全链路事件组件命名规范指导 #

1. 事件本身：保持你当前的[动作][领域]Event格式，比如UserCreatedEvent、UserDetailsUpdatedEvent，语义清晰，符合领域驱动设计的事件命名习惯。
2. 事件发布者（Http Trigger Function）：
   • 如果是统一接收所有通知事件并发布到Topic：命名为NotificationEventPublisher
   • 如果是单事件专属的发布函数：命名为[事件类型]Publisher，比如UserCreatedEventPublisher
3. 事件处理者（Service Bus Topic Trigger Function）：
   • 基础场景：[事件类型]EventHandler，比如UserCreatedEventHandler、UserDetailsUpdatedEventHandler
   • 多渠道通知场景：如果需要区分通知渠道（邮件/短信/推送），可以加上动作后缀，比如UserCreatedEmailNotificationHandler、UserDetailsUpdatedSmsNotificationHandler，进一步明确职责
4. Service Bus资源：
   • Topic：用通用领域名，比如UserNotificationsTopic
   • 订阅：与Handler一一对应，比如UserCreatedNotificationSubscription、UserDetailsUpdatedNotificationSubscription，直观体现订阅的筛选目标

内容的提问来源于stack exchange，提问作者Rakesh Kumar