我正在尝试将遗留订单处理和库存系统重构为更清洁的面向服务的事件驱动架构。但是,我在决定由什么服务负责库存的预定/分配时遇到了一些困难。
当前系统的简要概述
已通过第三方系统向我们下达了销售订单,但我们不一定有所有的订单行库存。
当物料从供应商处到达时,系统将搜索所有未清销售订单中的物料,并按销售订单日期对它们进行储备/分配。 ***
我已经确定了我认为需要开发的两项服务
销售-负责接收销售订单并将其插入数据库。具有域实体,例如Order,OrderLine等。
库存-负责跟踪仓库中有多少库存。具有域实体,例如StockItem。
但是,由于库存的分配/保留既涉及库存又涉及销售,所以我不确定应将上述第2点中的行为放在哪里。
我对此有任何帮助或想法。
答案 0 :(得分:2)
但是,由于库存的分配/保留既涉及库存又涉及销售,所以我不确定应将上述第2点中的行为放在哪里。
我一直在考虑这个问题(纯粹是在学术上),而我目前的结论是预订管理属于库存系统。这样可以将库存来源(从您的供应商处采购的物品的装货)和库存接收器(订单的履行)保持在一起。
因此,库存系统会缓存其自己的数据副本,以填写订单(允许其自主运行)。通知供应商提供了新的库存后,即使销售系统因维护而发生故障,它也应该能够取得进展。
答案 1 :(得分:1)
我认为您有2个BC(受限环境):库存和销售。对于它们之间的集成,我可能会选择领域事件方法。
当有新物品到达仓库时,库存BC会增加该物品的库存并发布事件。
销售BC订阅了该事件,并更新了正在等待库存项目的已开销售。
因此,“点2”的行为由两个BC共享:
销售BC搜索等待该项目的未结订单。然后,它要求库存BC获取所需的物品数量(此请求是同步的)并关闭订单。
库存BC收到请求并减少了该项目的库存。
答案 2 :(得分:0)
您提到SOA和NServiceBus,所以我最初的想法是您已经参加Udi Dahan的ADSD培训了吗?我假设你有。这样,我将尝试回答您的问题。
到目前为止,我还没有很多信息。但是有了这些,我认为我们需要这些属性来存储您提到的所有内容。
如果您有一个OrderId,则可以附加一个或多个ProductId来创建实际的订单。从技术上讲,此存储方式不同。可能在具有Order和OrderLine表的关系数据库中,或者可能在所有内容都存储在单个文档中的DocumentDb中。在这一点上这是完全不相关的。
假设我们需要4个属性,我不确定为什么我们要创建1个以上的服务来拆分它?当我们有更多信息时,这可能会更改,但是目前我看不到需要。
如果您想讨论这个问题,请通过support@particular.net与我们联系,提及我的名字,我们可以继续进行对话。
答案 3 :(得分:0)
您说的是松散耦合的域应用、管理您的销售订单、管理您的库存和管理您的采购订单。 库存必须始终是最新的,以免销售您无法交付的产品。所以 PO en SO 应用程序都应该通过同步(库存)服务与库存对话。为了保持一切一致,采购方的事件(例如收到的 PO 少于您的预期)将对已分配该 PO 数量的任何 SO 产生影响,如库存中持续存在的那样。因此,例如,相同的 PO pcs,其中注册了接收不到预期的事件,应该同步更新库存,更新可供 SO 分配的可用数量,并发布一个事件,以异步方式提取So 应用程序,以便用户可以收到通知并讨论相关操作。等