Night Market 技能 — 来源于 claude-night-market/archetypes。如需获得包含智能体（agents）、钩子（hooks）和命令（commands）的完整体验，请安装 Claude Code 插件。

事件驱动架构范式

适用场景

• 构建异步、松耦合的系统
• 具有复杂事件处理流水线的系统

不适用场景

• 无需异步能力的简单请求-响应型应用
• 对强事务一致性有严格要求的系统

应采用该范式的典型场景

• 面向实时或突发性工作负载（例如 IoT、金融交易、物流），其中松耦合与异步处理具备显著优势。
• 多个相互独立的子系统需对同一业务或领域事件作出响应。
• 系统可扩展性为高优先级需求，允许新增组件而无需修改现有服务。

落地实施步骤

1. 建模事件：定义规范化的事件 Schema，确立清晰的版本管理策略，并为每类事件指定明确的所有者。
2. 选择合适的拓扑结构：针对每条数据流，审慎决策采用编排（choreography，例如简单的发布/订阅模型）还是编排（orchestration，例如中心化控制器或 Saga 编排器）。
3. 构建事件平台：选用合适的事件代理（event broker）或消息网格（message mesh）。配置关键参数，如消息顺序保证、主题分区（topic partitions）及数据保留策略。
4. 规划失败处理机制：实现生产级的消息失败应对方案，包括死信队列（DLQ）、自动重试逻辑、幂等消费者（idempotent consumers），以及支持事件重放的工具链。
5. 增强可观测性：部署细粒度监控，追踪核心指标，如消费者延迟（consumer lag）、消息吞吐量、Schema 校验失败率，以及各消费者应用的健康状态。

关键交付物

• 一份架构决策记录（ADR），内容涵盖事件分类体系、所选代理技术栈，以及治理策略（例如命名规范、版本策略与数据保留规则）。
• 一个集中式 Schema 仓库，集成自动化 CI 校验与消费者驱动的契约测试（consumer-driven contract tests）。
• 面向运维的可视化看板，用于监控全系统吞吐量、消费者延迟及 DLQ 深度。

风险与应对措施

• 通过事件引入的隐式耦合：
  • 应对措施：消费者可能隐式依赖未文档化的事件语义或字段。应发布正式的事件目录（event catalog）或 Schema 注册中心（schema registry），并使用 Lint 工具强制校验事件结构。
• 运维复杂性与“噪声”问题：
  • 应对措施：若缺乏强有力的可观测性能力，定位失败或“卡住”的消费者将极为困难。应在所有事件驱动组件中强制推行分布式追踪（distributed tracing）与标准化告警机制。
• “事件风暴（Event Storming）”导致的分析瘫痪：
  • 应对措施：尽管事件风暴工作坊极具价值，但若缺乏有效引导，易陷入低效讨论。建议严格限定建模会话时长，并优先聚焦于高价值业务上下文。

具体组件

以下术语指代该范式落地时实际出现的具体工具与抽象概念。它们并非强制依赖项，也不属于本技能 tools: 前置元数据（frontmatter）中声明的内容（该字段专用于约束 Claude Code 的可用工具）。请在架构讨论中参考此列表以消除歧义。

• message-broker — Kafka、NATS、RabbitMQ；生产者与消费者之间的持久化通信通道
• event-stream-processor — Flink、Faust 或同类技术；消费事件流并输出衍生事件
• distributed-tracing — OpenTelemetry 风格的跨异步调用链路的关联 ID 机制