上次我们讨论了大局事件风暴 (BPES)，现在我们对业务流程有了一个大概视角。接下来，我们需要深入并对子流程进行建模，以解决我们的业务需求和问题。为此，我们将使用流程级事件风暴 (PLES)。
回到 BPES 研讨会，我们可以注意到整个流程中存在一些较小的、自主的子流程。现在我们可以专注于每一个并处理细节。PLES 为我们提供了一些额外的元素来帮助我们完成这项工作。
我们与我的客人一起创建了一个负责禁止招聘人员的部分。然后我决定独立完成剩下的事情，因为我不想占用他们更多的时间。
在 BPES 级别，我们仅使用事件。现在，我们将使用一些新元素，您可以在上图中注意到。因此，让我们花点时间仔细看看它们和整个周期：
用户基于现实世界的某种冲动，决定采取行动。通常，他们的决定是由系统信息驱动的（阅读模型 - 绿色便签）。
用户正在采取行动（命令 - 蓝色便签），该操作将由系统处理（粉色便签）。结果，将产生事件（橙色音符）——有关系统更改的信息。
当事件发生时，可能会发生两件事：
对此类事件的政策/反应（紫色注释），这将导致新的命令
读取模型的变化，这反过来又可以为用户提供新的信息来做出其他决策。
好吧，现在让我们将这些知识运用到实践中吧！首先，我们来仔细看看广告的起草过程。
草稿
BPES 研讨会结束后，这部分内容如下
现在让我们想想这个过程应该是什么样子。谁应该做出决定？该决定应基于什么信息？事件需要任何反应吗？必须发生什么才能触发特定事件？总而言之：我们需要利用从“图片说明一切”中获得的知识。多亏了它，我们可以在这里设计如下流程
在我们继续之前，请注意紫色/淡紫色的音符。这些是策略——不要将它们与策略/策略设计模式混淆。这里是对某些事件的反应，这些事件应该触发命令。布兰多里尼在他的书中对它们进行了如下描述：
“当然，必须对这一事件做出一些反应。我们可以使用（淡紫色）策略捕获反应逻辑，例如“每当我们收到订单时，我们就会将相应的披萨添加到待办事项中。”
好吧，我们回到广告稿的建模上来。当程序员（候选人）通过填写广告表格 (1) 创建草稿时，一切就开始了。这是系统应该存储这些数据的信息，以防用户想要稍后完成整个过程。换句话说：我们创建一个形式（2）的读取模型。当用户对表单进行任何更改时，草稿的内容将发生更改 (3)。从领域层面来看，我们对到底发生了什么变化并不感兴趣。我们只关心它被更改的事实，以便我们可以更新读取模型。然后，当用户完成表格并选择支付选项时，他/她支付广告费用(4)。现在外部支付系统启动并最终向我们提供支付是否成功的信息 (5)。最后，您可以注意到一个有趣的商业决策：无论发生什么，我们都会发布广告（6）。我决定让这部分过程变得不那么复杂。我认为外部系统中支付失败的情况非常罕见。专注于所有可能出错的案例并推迟发布是没有意义的，至少在业务开始时是这样。现在，我们无论如何都要发布，当我们最终得到付款失败的信息时，我们可以将此信息发送给客户支持。他们可以决定如何处理广告。也许他们会重新触发付款、删除/屏蔽广告或联系开发商澄清情况。如果我们得到的信息是这样的情况太多了，那么我们就应该解决这个问题。
现在，让我们以敏捷的方式来做吧 🙂
值得注意的是，当我们创建草稿时，另一个并行进程就会启动（7）。它的职责是删除所有逾期的草稿，而不是将它们在我们的系统中存储太久。因此，首先，我们给他们一些生存时间（TTL）。然后，每次更新草稿时，我们都会更新该时间 (8)。最后，当超出 TTL 且开发者未发布广告时，我们会删除草稿 (9)
登记
每个应用程序都有一个注册，对吧？这是一个非常通用的流程，因此我们在 BPES 期间并不关心它。这意味着我无法向您展示“之前”的状态。即使在 PLES 之后，也无需考虑太多：
通常，人们相信“我们的项目是具体的”。这就是为什么如此多的应用程序实现了一个单独的服务，即使我们不使用任何现成的解决方案，我们也会将此过程简化为一个步骤。
发布流程
付款后，广告可以在系统中查看和搜索。然而，当付费时间到期时，广告的生命周期结束。在此期间，由于各种原因，广告可能会被取消发布或再次发布。这就是为什么我们将整个过程称为 "发布过程"。通常，当我们注意到 "发布 "和 "未发布 "状态时，我们可以尝试建立独立的可用性子域模型。但是，我们现在不这样做，我们将继续使用更大的发布子域
让我们一步步描述这个过程。付款后，我们收到发布广告的请求 (1)。我们对此作出反应，使其可供搜索和查看 (2)。当我们发布广告时，我们也开始了它的可用期。当期限结束时，我们将广告从服务中删除 (3)。为了使这一过程保持简单，我再次决定跳过用户可以延长这一期限或在旧广告的基础上创建新广告的情况。
当广告发布时，有两种情况可能发生：
开发者可以决定取消发布 (4)。这可能发生在广告还有一些付费时间的情况下（当广告已经 "过期 "时，取消发布是没有意义的）。然后我们搁置广告 (5)。这意味着用户的不活跃广告列表被更新。基于该列表，开发人员可以决定再次发布该广告（6）。
另一种可以暂时搁置广告的情况是客户支持。整个过程与前一种情况类似，但做出决定的人不同。此外，他们还根据其他前提或数据做出决定。当客户服务部门收到有关广告的投诉时，他们可以暂时搁置广告(7)。
值得注意的是，在这两种情况下，当广告被搁置时，我们不会减少付费时间。相反，当广告恢复时，我们将重新开始。
提醒您一下BPES之后这部分的情况：
搜索
在BPES中，可能会发生某些事件实际上并不是事件的情况。一个很好的例子就是 "发现广告 "事件。
搜索与我们系统中的更改/修改无关。这只是一个查询。然后，根据可用的过滤器，招聘人员向系统询问符合所选标准的广告。这就是为什么在PLES中，我们决定将这一部分表示如下
报价
现在让我们把注意力集中在关键过程--提供。这是我们的解决方案区别于一般方法的部分。首先，招聘人员必须接受所有开发人员的需求，如果他们想提供任何需求的话。然后，可以阅读、拒绝或添加到收藏夹。
在PLES会话之后，该过程如下：
一切从广告页面开始。招聘人员看到广告后，可以发出招聘意向 (1)。他们需要接受所有要求并提供一些联系方式。然后，开发人员可以在offer页面(2)上看到offer的详细信息。该页面可以作为几个不同操作的 "起点"。从建模的角度来看，最有趣的是 "标记为已打开"（3）。注意用户界面会触发这个操作。您可能会问为什么。 所以用户界面会将新的报价显示为......新的--而不是 "已读"。然后，开发人员可以点击其中任何一个查看详细信息。这个操作本身并不会改变系统的状态，因为在这种情况下，我们只是查询系统的更多信息。此外，我们可能已经获取了这些详细信息，但被用户界面 "隐藏 "了。这就是为什么在显示（有时在1-2秒后）这些详细信息后，用户界面会发送命令将报价状态更改为 "已打开"/"已阅读"。您可以在电子邮件客户端中看到类似的功能。
开发人员触发该页面上的其余命令。这些命令可以是：拒绝要约（4）或添加到收藏夹（5）。
验证
在Big Picture Event Storming中，这个过程就已经非常有趣了。这是因为我们清理了许多外部系统特有的事件，而不是我们的。提醒您一下BPES之后的情况：
该事件通知我们验证过程的开始。我们想要实现的是给我们这边的整个过程一些TTL（生存时间）。这听起来有点......复杂。我们和外部系统之间仍然存在着很大的耦合。在PLES部分变得更加复杂。这就是为什么我最终选择了一个简单得多的解决方案：
在这种方法中，我们不像前一种方法那样过分依赖外部系统。最重要的是，我们不认为这个系统会公开任何关于其验证进度的信息。与外部系统集成的唯一要求是，该系统公开带有可用测试和由特定开发人员解决的测试的API。让我们从头开始了解这个过程。首先，开发人员进入徽章页面，查看他们可以获得的徽章(1)。每个徽章都与外部系统中相应的测试相关联。这意味着开发人员被重定向到外部系统，并可以在那里开始解决测试问题。整个过程都在那里进行，我们甚至不应该关心发生了什么或需要多长时间。当开发人员完成测试后，他们可以回到我们的系统并启动同步 (2)。这意味着我们的系统将查询外部系统，以获得特定用户的测试结果。根据响应，我们可以检查开发人员是否获得了新的徽章(3)。如果是，我们将更新两个视图：开发人员徽章和待获得徽章(4)。
禁止招聘人员
最后但并非最不重要的一点是，我们发现了一个最有趣的过程。实际上，我们一开始就在模拟这个过程。
这部分在BPES之后：
在招聘流程结束后，我们希望让开发人员有机会对已经发出录用通知的招聘人员进行评估。我们假定，触发这一行动的可能是我们系统之外的东西(1)。例如，可能是招聘方在DevMountJob中接受的条件与实际条件完全不匹配。开发人员，基于招聘过程中的经验，对招聘人员进行评估。然后，评估结果会进入排名系统(2)。该系统会重新计算招聘者的综合评分。假设该值低于某个预定义的阈值。在这种情况下，我们应该向客户支持部门（3）发送投诉。现在，流程分为两条路径：
该说明有一定的处理时间(4)。如果客户支持部门没有在这段时间内处理，我们就需要处理。它将进入逾期备注列表。因此，我们可以监控在给定时间内未处理的请求数量。当出现过多请求时，或当新的请求出现在列表中时，我们可以引入一些通知。
在给定的时间内处理备注。客户支持部门将根据招聘人员的历史记录以及上次评估的开发人员给出的所有其他评估，做出以下两个决定之一：
禁止招聘人员 (5) - 招聘人员将收到包含联系方式的信息（可能通过电子邮件），以澄清情况。然后，客户支持部门可以解锁账户 (6)
拒绝注释 (7) - 客户支持部门可以在分析额外数据后拒绝注释。例如，一些邪恶的开发人员可能故意通过创建大量负面备注来降低招聘人员的得分😉。
我们得到的这个封禁流程模型其实很通用。我的意思是，在其他领域也有很多流程可以用同样的方法来设计。例如，退款流程就是其中之一。
