我是DDD和微服务领域的新手，我想对如何处理这种情况提供一些指导。
假设我有一个带有Orders的系统。每个订单可以有多个项目。因此，我认为这将是一个特定领域。
然后，当我查看更多订单时，我发现我们将提供以下内容：
因此，订单具有用于下订单和获取订单详细信息的API。而且还订阅了所有其他系统，这些系统发送更新以收集项目，订单交付位置和进度。
现在觉得Order域似乎具有以不同节奏缩放的组件/功能。例如。我只需要10个订单api实例，但是需要50个订单通知处理程序实例，我们也接受24/7的订单，但是我们仅在特定的日期和时间收集项目并交付订单。这两个共享大量数据（订单和订单中的项目），并且需要一直报告。
所以我最初的想法是让订单rest api和通知处理程序成为不同的可部署单元，但是共享相同的订单数据库表。
搜索此内容似乎被称为反模式，但是示例引用了不同的域，在这种情况下，它似乎是相同的域。
使用DDD和微服务时，您将如何处理？是否存在我可以阅读更多有关的已知问题/模式？
谢谢！
答案 0 :(得分：1)
您将专注于数据而不是上下文。 数据存储库的重点是序列化上下文，仅此而已。因此，跨上下文是否存在数据重复并不重要，只要不是因为上下文定义不正确而导致重复即可。
例如，您的“订单”上下文可能包含“订单描述”，在“交付”上下文中，您可能需要该描述作为“邮政标签”。您将在2个地方保存相同的描述，这没关系。您将来可能会决定在“邮政标签”上添加“交货ID”，并且由于您具有单独的上下文，因此这种添加将是微不足道的，并且不会以任何方式影响您的订单上下文。
我不明白您所说的“ 10个订单api实例或50个通知处理程序”的含义。所以我无法解决这个问题。
因此，订单具有用于下订单和获取订单详细信息的API。而且还订阅了所有其他系统，这些系统发送更新以收集项目，订单交付位置和进度。
订单上下文不需要处理收集项目，交货或位置。或他们的活动。您还需要一个Delivery Context，可能还需要一个Gathering Context。
总而言之，将相同的数据保存在不同的上下文中是可以的，只要它在通用语言中有意义即可。另外，针对系统的主要功能（订单，收集和交付）设计上下文。