什么时候使用域事件？答案

【问题标题】：when to use domain event?什么时候使用域事件？
【发布时间】：2013-06-24 16:43:31
【问题描述】：

在 DDD 中，我想知道什么时候应该使用域事件？有适合使用领域事件的情况推荐吗？是否仅适用于最终一致可以接受的情况？

假设在具有 Product、Order、OrderLine 的在线商店示例中，一个 Order 包含多个 OrderLine。一个 OrderLine 和 Product 是一对一的关系，当我创建一个订单的同时，我需要扣除 Product 中的可用金额。我知道有两种方法：

In OrderService（应用服务）：
- 新建订单，插入数据库
- 对于 Order 中的每个订单行，获取与该 OrderLine 关联的产品，调用 Product.UpdateQuantity()
- 将所有产品保存到数据库
- 注意：在我看来，应用服务似乎完成了这里的大部分工作（创建订单、获取产品、更新产品），是否可以接受？
在订单服务中：
- 新建订单，插入数据库
- 生成一个事件 OrderCreated
- 触发事件处理程序，调用 Product.UpdateQuantity()
- 注意：产品数量不保证立即更新

在现实生活中，哪种方式更受欢迎？在这两种情况下，如何处理产品数量的并发更新？如果数量与用户看到结帐屏幕的时间不同，则通知用户失败？

非常感谢

【问题讨论】：

“现实生活”和DDD属于同一个句子吗？当我阅读这本书时，我很喜欢它，但感觉就像是那些已经被传递的想法之一。
哈哈，我之前没有机会看到现实生活中的DDD应用，所以我不能说它们是否互斥，但即使不是，我认为我有很多概念可以借鉴

标签： concurrency domain-driven-design aggregate domain-events

【解决方案1】：

我认为您的决定需要围绕工作单元和 ACID。

如果此服务拥有数据库并代表用户访问此信息的唯一接口，则该方法需要是单个工作单元，由服务作为一个事务进行管理。

我不明白您提供的两个示例之间的区别。

当我在亚马逊上订购商品时，我希望看到我的订单产品数量会立即更新并与我的订单保持一致。我不知道他们的库存系统是否“稍后赶上”或者它是否成为我交易的一部分。我不希望我的订单因为他们的库存系统有问题而失败。我可以看到他们可能有某种机制使我的订单持久且持久，并让库存系统稍后赶上（可能是队列）。但这是服务可能不需要知道的细节。

【讨论】：