Architecture 微服务-一个域和多个功能，以不同的速度扩展

我是DDD和微服务方面的新手，我想了解一些如何处理这种情况的指导

假设我有一个带有命令的系统。每个订单可以有多个项目。所以我认为这将是一个特定的领域

然后，当我查看更多订单时，我发现我们将提供以下服务：

• 订单中的每个项目都是从不同的仓库收集的，并且每个项目的状态（例如，已准备好、移动到收集点）以及ETA都会显示给客户，供其订购
• 收集所有物品后，我们会定期更新订单的状态、预计到达时间和gps位置

所以orders有API来下订单并获取订单详细信息。但也订阅了所有其他系统，这些系统发送项目收集和订单交付位置和进度的更新

感觉上的订单域现在似乎拥有以不同节奏缩放的组件/功能。例如，我只需要10个order api实例，但需要50个order notification handler实例，而且我们24/7接受订单，但我们只在特定的日期和时间收集项目和交付订单。这两者共享大量数据（订单和订单中的项目），并且需要随时一起报告

所以我最初的想法是让order rest api和通知处理程序是不同的可部署单元，但共享相同的order数据库表

围绕此进行搜索看起来被称为反模式，但示例引用了不同的域，而在本例中，它似乎是同一个域

在使用DDD和MicroService时，您将如何处理此问题？是否有一个已知的问题/模式可以让我了解更多

---

谢谢

你陷入了专注于数据而不是上下文的困境。 数据存储库的重点是序列化上下文，仅此而已。因此，跨上下文是否存在数据复制并不重要，只要复制不是因为上下文定义不好

例如，您的订单上下文可能包含订单描述，而在交付上下文中，邮政标签可能需要该描述。您将在两个位置保存相同的描述，这没关系。您可能会决定在将来向邮政标签添加“delivery Id”，因为您有单独的上下文，所以此添加将是微不足道的，并且不会以任何方式影响您的订单上下文

我不明白你所说的“10个订单api实例或50个通知处理程序”是什么意思。所以我无法解决这个问题

所以orders有API来下订单并获取订单详细信息。但也订阅了所有其他系统，这些系统发送项目收集和订单交付位置和进度的更新

订单上下文不需要处理收集项目、交付或位置。或者他们的事件。您需要一个

交付上下文

，也可能需要一个

收集上下文

总之，在不同的上下文中保存相同的数据是可以的，只要它在普遍存在的语言中是有意义的。另外，根据系统中的主要功能（订单、收集和交付）设计上下文