业务事件(领域事件)是发生的事情，当它发生时，它会引起企业的预先计划的响应，或者在这里我们称之为“工作”。一类业务事件是在相邻系统内部发生的事情。使工作知道业务事件已经发生，因为每次发生都会为工作产生数据流。
业务事件是一个重大事件，不仅仅是单击鼠标。通常，这是对您的企业提供的服务的请求，而结果就是提供服务或产品。
例如，图1说明了客户决定支付账单的业务事件。事件发生的地方是相邻的系统（在这种情况下为Customer）。数据流（由事件引起）是客户付款。该流通常称为“触发数据流”，因为它触发工作的响应。在这种情况下，响应将是接受付款，记录付款并发送确认收据。所有这些都将根据工作的业务规则来完成。请注意，这些规则可能是由人员，技术或两者的结合来执行的。
跟踪业务事件
每当确认一个新的业务事件与工作范围相关时，业务分析师就会通过将事件添加到工作上下文图中来进行跟踪。图1显示了一个工作环境图，其中仅包含一个业务事件：客户决定支付账单。在图2中，还有一个额外的业务事件，客户下订单。您可以在图上看到此事件的其他流程。
图2：此工作上下文图包含两个业务事件。
每当您发现一个新的业务事件并且同意将其纳入您正在研究的工作范围内时，都应将其添加到工作上下文图中。每个业务事件都代表着有限的功能块，您可以独立于其他事件进行研究，同时跟踪各个事件如何适合整个事件。随着业务事件数量的增加，事件列表（如图3所示）可以帮助您管理调查并确定调查的优先级。当然，您的事件列表会更长。
活动编号 活动名称 输入 输出/秒 |
业务事件代表了重要且独立的功能块，可以对其进行优先级排序，以便您始终致力于产生最大价值的事件。业务事件还有助于组织调查。您可以在团队中分配事件，并且由于事件的独立性，团队成员之间无需过多互动。
与敏捷开发团队合作
业务事件对敏捷团队非常有效。业务事件（或正确地说，是对业务事件的响应）是问题的独立部分，具有明确的结果。它还具有定义明确的输入和输出。这不仅使它成为学习和查找其需求的便捷单元，而且使它成为一个明智的开发单元。
图4说明了这种方法。正如我们所看到的，范围是由业务事件的集合确定的，对于每一个事件，我们都主张编写业务事件的故事。这是常规意义上的角色-功能-结果的故事。稍后对此进行更多讨论。
对于每个业务事件故事，开发人员可以在业务分析师的帮助下，通过编写许多功能案例来定义对业务事件的响应的详细信息。这些代表功能的细分。开发人员可以通过编写实现功能故事所必需的详细任务来进一步细分它们。
图4：需求层次结构为迭代处理业务需求和实施需求提供了基础。工作范围包含许多业务事件，每个业务事件都有一个业务事件故事。每个业务事件故事都有许多功能故事。每个功能故事都有实现它所需的许多详细任务。使用故事地图可以有效地管理此层次结构。
图5提出了一种可追溯的技术，用于为业务事件推导业务事件故事。
图5：业务事件，触发数据流和事件响应是构建业务案例的组件。
由此产生的业务案例是：
作为客户， |
通过这种方法，开发人员可以从业务案例中获取业务功能案例。在此示例中，此业务案例的功能案例将类似于“查找客户帐户”，“记录付款”，“收据”。
如果对业务案例或功能案例有任何更改或疑问，则业务分析师，产品所有者和开发人员可以使用通用的交流语言。