Domain driven design 订单及；库存DDD-应在何处处理分配/预订？

我正在尝试将一个遗留的订单处理和库存系统重构为一个更干净的面向服务的事件驱动体系结构。但是，我很难决定哪些服务应该负责库存的预订/分配

当前系统的简要概述

销售订单是通过第三方系统向我们下的，但我们不一定有所有的订单行库存

• 如果订单项目有库存，我们会立即为该订单分配/保留库存
• 但是，如果我们没有足够的库存，那么我们通过采购系统从供应商处采购库存

当商品从供应商处到达时，系统将搜索该商品的所有未结销售订单，并根据销售订单日期为其保留/分配可用库存***

我已经确定了两项我认为需要开发的服务

• 销售-负责接收销售订单并插入数据库。具有域实体，如订单、订单行等

• 库存-负责跟踪仓库中有多少库存可用。具有域实体，如StockItem

然而，由于库存的分配/保留涉及库存和销售，我不确定上文第2点中的行为应该放在哪里

我欢迎任何关于这方面的帮助或想法

然而，由于库存的分配/保留涉及库存和销售，我不确定上文第2点中的行为应该放在哪里

我一直在思考这个问题（纯粹从学术角度），我目前的结论是预订管理属于库存系统。这将使库存源（从供应商处采购的物品的装载）和库存接收器（订单的履行）保持在一起

因此，库存系统缓存填写订单所需的数据副本（允许其自主工作）。一旦得知供应商提供了新的库存，即使销售系统碰巧因维护而停机，它也应该能够取得进展。

我认为您有两个BC（有界上下文）：库存和销售。对于它们之间的集成，我可能会选择域事件方法

当新项目到达仓库时，库存BC会增加该项目的库存，并发布一个事件

Sales BC订阅该事件，并更新等待库存项目的已打开销售

因此，“第2点”的行为是由两个BC共享的：

• 销售业务连续性搜索等待该商品的已打开订单。然后它要求Inventory BC获取它需要的项目数量（此请求是同步的），并关闭订单

• 库存BC收到请求并减少该项目的库存

---

您提到了SOA和NServiceBus，所以我最初的想法是您参加了Udi Dahan的ADSD培训？我想你有。有了这些，我将试着回答你的问题

到目前为止，我没有太多的信息。但就我们所拥有的，我想我们需要这些属性来存储您提到的所有内容

• ProductId，每个可用产品一个
• InventoryTotal，附加到ProductId。这个数字上下浮动
• OrderId，以创建订单
• OrderDate，以确保我们可以找到应首先接收进货的订单

如果您有OrderId，则可以附加一个或多个ProductId以创建实际订单。不同的技术存储方式。可能是在具有Order和OrderLine表的关系数据库中，也可能是在DocumentDb中，其中所有内容都存储在单个文档中。这在这一点上是完全不相干的

假设我们需要4个属性，我不确定为什么我们要创建多个服务来拆分它？当我们有更多信息时，这种情况可能会改变，但目前我认为没有必要

---

如果您想讨论此问题，请联系我们support@particular.net，提到我的名字，我们可以继续对话。

您所说的是松散耦合的域应用程序，管理您的销售订单、管理您的库存和管理您的采购订单。

---

库存必须始终是最新的，以便不出售你不能交付的东西。因此，PO en-So应用程序应通过同步（库存）服务与库存进行对话。为了保持所有内容的一致性，采购方的事件（如收到的采购订单少于您预期的数量）将对库存中已分配的采购订单数量产生影响。因此，同一个PO PC（例如，在该PC中，收到的数量低于预期）应同步更新库存，以更新SOs可分配的数量，并在So应用程序中异步发布事件，以便通知用户并讨论相关行动。等等。

但是，由于库存分配/预订涉及库存和销售

-它与销售有何关系？执行分配/预订的人员需要知道哪些销售订单在等待库存，以便能够以正确的顺序分配，即先分配最旧的订单。我们还需要针对销售订单行更新“AllocatedQty”字段。我仍然看不到库存与销售的关系。这是什么

AllocatedQty

？我想我在我原来的帖子中遗漏了一个要点。我们的销售订单存储在一个单独的数据库中，与我们的产品和库存信息相关联，我们正在进行的这个项目不太可能更改。