Microservices 用于微服务的DDD数据复制

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

可以吗

或者我该怎么办

可以吗

从我的观点来看，在微服务体系结构中，如果出于正确的原因，复制所需数据本身是完全可以的。我甚至不一定首先把它看作是一个正常的数据复制。

每个微服务都有自己的域模型，因此用户模型-您已经在不同的服务（付款人、卖家等）中对其进行了不同的命名-在不同的上下文中表示不同的内容。很可能还会有数据添加到每个服务中的那些用户对象，而这些用户对象甚至不为用户服务所知

或者我该怎么办

。。。但您仍然应该考虑每个服务中用户数据的表示。用户一创建，就可能不需要在每个服务中构建用户模型（卖方、买方等）的投影

---

我只会在需要执行一些域逻辑时，在产品服务中已经有一些用户信息在手的情况下这样做。您很可能只需要其中一个服务中相应用户的id（或者说唯一用户名）就可以将用户连接到某个域实体。或者您甚至可以根据需要创建相应的用户对象，例如在结账过程中。

我同意afh的回答

在每个有界上下文（BC）中使用不同的域概念模型（在本例中为用户）是一条可行之路。在用户BC中，您有一个模型，该模型仅用于管理与任何其他BC无关的用户及其信息。在其他BC中，您拥有买方的购买数据、卖方的销售数据和用户BC的参考ID。现在，出于优化和隔离的原因，您可能会发现需要在支付BC中复制一些用户BC数据，以避免查询到另一个BC来完成某些操作；那就好了

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

---

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

是，这是可以的-15000个用户的60000个用户记录不是很多，但是如果用户是1500.000或更多。每项服务都有150万用户。这意味着所有系统都有6.000.000个用户？是的，这仍然可以。我不明白你为什么认为这可能是个问题？看看这个答案，我想问一些问题。假设我有一个篮子服务，它以只读方式存储产品。产品与事件同步。篮子服务不需要产品服务可用性，但最终需要一致性。。或者聚合器网关服务从产品服务和其他具有强一致性的服务中获取产品（一致性对于一揽子服务中的库存或价格很重要）。哪一个？如果你能争取最终的一致性或强烈的一致性，一般都无法回答。这是您需要根据业务需求来决定的。如果最终的一致性还可以，您可以通过事件（例如，通过消息传递基础设施）跨其他服务分发产品更新，这些服务根据接收到的事件更新自己的数据存储。或者，您也可以研究分布式事务的一种协调方法，并研究其性能。如果您确实需要强大的一致性（而不是最终一致性），您可能需要重新考虑服务边界。应保证服务内的强一致性。您可以在需要的地方合并服务，也可以根据需要从拥有它的微服务查询关键数据。但是，这样做会失去可用性和可扩展性的好处，因为，例如，篮子服务将依赖于调用产品服务来执行所有操作。根据我的个人经验，通常更好的做法是意识到可能出现的陈旧数据情况，并能够处理它，而不是试图避免它。通常情况下，这种情况不应该经常发生。如果您通过事件发布更改，则很有可能出现不同步的情况。