微服务的DDD数据复制

Question

我有用户，付款，产品，结帐服务。用户付款方式；付款人，产品；卖方，结帐：买方等。新用户注册时。我发布了包含用户的事件。并存储所有服务的用户数据。这意味着所有服务的15000用户是X4 = 60.000用户数据。

可以吗？

或者我该怎么办？

Answer 1

可以吗？

从我的观点来看，如果出于正确的原因发生，那么在微服务架构中，

必需数据本身的重复完全可以。而且我什至不必一开始就认为这是正常的数据重复。

每个微服务都有其自己的域模型，因此 User 模型-您已经在不同的服务（付款人，卖方等）中使用了不同的名称-表示某种东西在不同的情况下有所不同。很有可能还会向每个服务中的用户对象添加数据，而这些数据甚至是用户服务所不知道的。

或者我该怎么办？

...，但您仍应考虑每个服务中用户数据的表示形式。创建用户后，甚至不必在您的每个服务中都构建用户模型的预测（卖方，买方等）。

仅当我需要手头已有一些用户信息（例如，产品服务，而必须执行某些域逻辑）时，我才这样做。您很有可能只需要其中一项服务中相应用户的ID（或者说是唯一的用户名）即可将用户连接到某个域实体。或者，您甚至可以根据需要创建相应的用户对象，例如在结帐过程中。

Answer 2

我同意回答。

在每个有界上下文（BC）中都使用不同的领域概念模型（在这种情况下为User）。在用户BC中，您仅具有管理用户及其与任何其他BC不相关的信息所需的模型。在其他BC中，您具有买方的购买数据，卖方的销售数据以及用户BC的参考ID。现在，出于优化和隔离的原因，您可能发现需要在Payment BC中复制一些User BC数据，以避免查询另一个BC来完成某些操作；然后复制就可以了。

这是DDD和/或微服务中的黄金法则。不要尝试在服务器BC中重用源代码模型（至少默认情况下）。这也适用于DDD角色。域概念（用户）可以在一个BC中充当聚合体，在另一个BC中充当实体，在另一个BC中充当VO；因此您需要在3个不同的BC中使用3个不同的模型。

还请记住，您的视图不是域操作。如果您必须显示（只是显示；如果您需要BC流程的规则和不变量的数据，则此数据属于BC流程；这可能导致可能的数据重复）您在支付BC流程中的用户BC数据是允许同时查询BC或查询出于性能目的而构建的非规范化ReadModel等