我是DDD和微服务的新手，我想了解如何处理这种情况。
假设我有一个订单系统。每个订单可以有多个项目。所以我认为这将是一个特定的领域。
然后，当我查看更多订单时，我发现我们将提供以下服务：
- 订单中的每个项目都是从不同的仓库收集的，每个项目的状态(例如准备好，移动到收集点(以及ETA都会显示给客户的订单
- 收集完所有项目后，我们会定期更新订单的状态、eta和gps位置
因此订单有API来下订单并获取订单详细信息。但也订阅了所有其他发送物品收集、订单交付位置和进度更新的系统。
现在，秩序域似乎有一些组件/函数以不同的节奏进行缩放。例如，我只需要10个订单api实例，但需要50个订单通知处理程序实例，而且我们全天候接受订单，但我们只在特定的日子和时间收集物品并交付订单。这两者共享大量数据(订单和订单中的项目(，需要始终一起报告。
因此，我最初的想法是让订单rest api和通知处理程序是不同的可部署单元，但共享相同的订单数据库表。
围绕这一点进行搜索似乎被称为反模式，但示例引用了不同的域，而在这种情况下，它似乎是同一个域。
在使用DDD和微服务时，您将如何处理此问题？有没有一个已知的问题/模式可以让我了解更多？
谢谢！
您一直在关注数据而不是上下文。数据存储库的目的是序列化您的上下文，仅此而已。因此，跨上下文是否存在数据重复并不重要，只要重复不是因为上下文定义不周。
例如，您的订单上下文可能包含订单描述，而在您的交货上下文中，您可能需要该描述作为邮政标签。您将在两个位置保存相同的描述，这没关系。您可能会决定在未来将"delivery Id"添加到邮政标签中，由于您有单独的上下文，因此此添加将是微不足道的，不会以任何方式影响您的订单上下文。
我不明白你说的"10个订单api实例或50个通知处理程序"是什么意思。所以我不能解决这个问题。
因此订单有API来下订单并获取订单详细信息。但也订阅了所有其他发送物品收集、订单交付位置和进度更新的系统。
订单上下文不需要处理收集项目、交货或地点。或者他们的事件。您需要一个Delivery Context，也可能需要一个Gathering Context。
总之，在不同的上下文中保存相同的数据是可以的，只要它在普遍语言中是有意义的。此外，根据系统中的主要功能(订单、收集和交付(设计您的上下文。