Domain driven design DDD/事件来源，从另一个微服务获取数据？
我想知道你是否能帮忙。我正在编写一个订单系统，目前已经实现了一个订单微服务，负责下订单。我将DDD与事件源和CQR一起使用 订单服务本身接收生成事件的命令，实际的订单服务侦听自己的事件以创建读取模型（这里的想法是使用CQR，因此用于写入的命令和用于读取的查询） 在执行上述操作后，我遇到了一个问题，可能是因为我没有完全理解正确的方法 订单实际上有依赖项，这意味着订单需要客户和产品。因此，我将为客户和产品提供另外两项微服务 为了简单起见，我想把重点放在客户身上（虽然我对产品有完全相同的问题，但我的想法是，如果我解决了客户问题，那么另一个问题也会自动得到解决） 那么回到手头的问题上来。为了创建订单，订单需要一个客户（和产品），我目前在客户机上有customerId，因此向订单服务发送命令，我可以传递customerId 我想在订单中保存客户的姓名和地址。如何从订单服务中的客户服务获取客户ID的名称和地址 我想总结一下，当来自一个服务的数据需要来自另一个服务的数据时，我如何才能获得这些数据 订单服务是否会创建接收客户记录的事件？这将在系统中引入很多复杂性（更多事件） 微服务是不耦合的，因此订单服务不能仅仅调用客户的读取模型Domain driven design DDD/事件来源，从另一个微服务获取数据？,domain-driven-design,microservices,cqrs,event-sourcing,Domain Driven Design,Microservices,Cqrs,Event Sourcing,我想知道你是否能帮忙。我正在编写一个订单系统，目前已经实现了一个订单微服务，负责下订单。我将DDD与事件源和CQR一起使用 订单服务本身接收生成事件的命令，实际的订单服务侦听自己的事件以创建读取模型（这里的想法是使用CQR，因此用于写入的命令和用于读取的查询） 在执行上述操作后，我遇到了一个问题，可能是因为我没有完全理解正确的方法 订单实际上有依赖项，这意味着订单需要客户和产品。因此，我将为客户和产品提供另外两项微服务 为了简单起见，我想把重点放在客户身上（虽然我对产品有完全相同的问题，但我的想
有谁能在这方面帮助我吗？我的建议是在前端收集所需的数据并传递出去。要在订单中反规范化的相关客户详细信息将是一个值对象。与订单行相关的产品数据（如id、说明）也是如此 让系统交互以检索数据并非不可能，但这确实在较低的级别上将它们耦合起来，这似乎是必要的 当来自一个服务的数据需要来自另一个服务的数据时，我如何才能获得这些数据 你复制它 因此，在您的设计中的某个地方，需要有一条消息将数据从它所在的位置传送到它需要的位置 这可能意味着订单服务订阅由客户服务发布的事件，并存储它所需的信息副本。也可能是订单服务查询一些API，这些API可以直接访问客户服务存储的数据 对您需要的其他数据的查询可以是同步的，也可以是异步的——也许工作可以推迟到您拥有所有需要的数据之后 另一种可能性是重新设计系统，以便所需的业务功能与数据一起使用，或者移动功能，或者移动数据。为什么订购需要客户数据？客户服务部能代替它做这项工作吗？你应该拥有这些数据吗
在您决定跨多个服务分发工作时，存在一定程度的复杂性。分发系统的决定涉及权衡各种利弊。如果您使用的是DDD，首先请阅读有界上下文。忘记微服务吧，它们只是实现策略 现在回到你的问题上来。从Customer aggregate（在您的案例Customer microservice中）发布这些事件：
CustomerRegisteredCustomerInfo更新CustomerAccountUntremovedCustomerAddressChanged答案可能会有所不同。我会说，从性能角度来看，硬盘中的空间比内存便宜，或者数据库查询比网络调用快。如果您的数据库主机（或服务器）受到限制，则不应使用微服务。此外，我会利用这些未使用的客户数据提出一些商业想法，例如列出所有从未订购过任何东西的客户，我会向他们发送一些报价，以发展我的业务。只是开玩笑。不要为微服务中未使用的数据感到烦恼。当您说“我想在订单中保存客户的姓名和地址”时，假设您所说的是订单的查询/读取模型是否正确？是的，这是正确的