如何从CRUD中捕捉意图事件？

CRUD（创建读取更新删除）虽然看起来很简单，但在大型系统中，它常常会导致代码混乱、复杂。

创建、读取、更新、删除 (CRUD) 非常常见。一般来说，它只是简单的表单，用于将数据添加到数据库并提供记录列表，您可以深入到特定记录以修改/更新现有记录或可能删除它们。通常，它们实际上只是围绕数据库的 UI 和 API。

例如产品的当前价格为 30.99 美元。如果有人将该值更改为 10.99 美元并保存怎么办？
当然，它更新了该产品的数据库记录，现在该产品将以新价格出售。

但作为最终用户，我们到底在做什么呢？我们为什么要改变价格？
我们不知道。我们不知道他们改变价格的商业原因。更改价格有商业原因，但 CRUD 类型的系统在许多情况下无法捕获它。当然，我们可以尝试暗示原因，但我们不知道。

我们希望我们的最终用户是明确的。我们希望他们准确地告诉我们他们在做什么，并捕捉到他们的意图。他们不仅仅是在更新产品或改变价格。他们在做一些具体的事情。

例如，我不仅仅是将价格改为 10.99 美元。这可能是因为我们正在以大幅折扣价进行限时闪购。

• 改变价格背后有商业意图。这不仅仅是 "改变价格"。
• 要知道原因，我们必须为用户提供他们需要的业务功能。
• 如果闪购是一个概念，那么我们就需要为他们提供这样的能力。
• 为此，我们需要以任务为导向。

CRUD作为闪购的解决方案
也可以开发一个CRUD闪购系统，让用户通过闪购前端去改变价格。

这样，商品价格改变来自了两个模块，一个是传统正常出售场景；一种是闪购打折场景，这两者商品价格由于位于不同上下文场景，被限制于这两个上下文模块，因此是不同的东西，不同的价格，没有必要混合在一起。

是否有必要引入事件的解决方案
如果我们以上下文BC为指导，CRUD并不会复杂化问题。

但是，如果没有上下文BC划分不同场景的意识，那么通过引入领域事件也可以从另外一个角度解决：

• 上下文划分是一种静态结构划分，属于事前规划，取决于人的规划能力。
• 领域事件则是以一定复杂性为前提，提供系统扩展新能力，如果闪购不是一种常见场景，不需要固化，一年或几年一次，那么使用事件方式可能灵活一些。

步骤：

• 如果我们开始闪购，我们可以发布一个价格变动这一事件来表明
• 然后，我们就可以对发生的事件做出反应，执行其他类型的操作。

而价格变动的结果会出现在当前正常销售的窗口中，价格变动事件会被记录下来，甚至可以为高级用户展示某个商品价格在一年之内的变动曲线，能让用户在价格最低时购买。