你提到过SOA和NServiceBus,所以我最初的想法是你参加了他的ADSD培训Udi Dahan?我猜你有。有了这个,我会尽力回答你的问题。
到目前为止,我没有太多的信息。但是凭借我们所拥有的,我认为我们需要这些属性来存储您提到的所有内容。
如果您有OrderId,则可以附加一个或多个ProductId来创建实际订单。技术上存储的不同方式。可能在具有Order和OrderLine表的关系数据库中,或者可能在DocumentDb中,其中所有内容都存储在单个文档中。在这一点上,这完全无关紧要。
假设我们需要4个属性,我不确定为什么我们会创建多个服务来拆分它?当我们获得更多信息时,这可能会改变,但此刻我认为没有必要。
如果您想讨论这个问题,请发送电子邮件至support@particular.net联系我们,提及我的姓名,我们可以继续进行对话。
但是,由于库存的分配/预留涉及库存和销售,我不确定上面第2点的行为应该放在何处。
我一直在考虑这个问题(纯粹是学术上的),我目前的结论是预订管理属于库存系统。这使得库存源(从供应商采购的物品的装载)和库存(订单的履行)保持在一起。
因此,库存系统会缓存自己填写订单所需数据的副本(允许它自动工作)。一旦被告知供应商提供了新的库存,即使销售系统因维护而停工,也应该能够取得进展。
我认为你有2个BC(有界的上下文):库存和销售。对于它们之间的集成,我可能会采用域事件方法。
当新项目到达仓库时,库存BC会增加该项目的库存,并发布事件。
销售BC订阅该事件,并更新正在等待库存项目的已开放销售。
因此,BC点共享“点2”的行为:
销售BC搜索等待该项目的已打开订单。然后它要求Inventory BC获取它需要的项目数(此请求是同步的)并关闭订单。
库存BC接收请求并减少该物料的库存。