我想问一些更哲学的问题。主题是 DDD 和微服务。 DDD 识别有界上下文。如果我理解正确，那么每个有界上下文都是整个系统的一小部分。例如，可能有订购上下文和发票上下文。每个上下文都与客户一起工作，但订购上下文无法了解发票设置，而发票无法了解订购设置。这是否意味着每个上下文都会有两个客户微服务？ 第二个问题是：如果我有订单微服务，我可以加载客户数据来评估一些条件，检查客户可以直接从数据库创建新订单还是需要通过客户微服务访问？
感谢您的意见。
【问题讨论】：
标签： domain-driven-design microservices bounded-contexts
首先，您必须知道，相同的概念在不同的上下文中可能意味着不同的事物。例如，在订单上下文中，实体客户可能意味着您可以交付东西的人，因此订单客户将具有诸如地址、首选交付时间等属性。
但是，如果我们在发票上下文中查看客户，这将意味着您可以获得付款的人，因此它将具有诸如信用卡号、贝宝帐户、首选付款类型等属性。
这么说，为了回答你的第一个问题，我认为没有必要有两个不同的客户服务，你应该有一个客户服务在自己的有界上下文中是首选的，当客户想要更新和查询时会调用它他自己的设置，以及客户在订单和发票上下文中的不同视图或投影实体，以及您在这些上下文中执行操作所需的信息。
在事件驱动的设计中，此实体将通过订阅更新客户事件根据服务上下文进行更新，因此当产生任何对交付或付款选项的修改时，此实体将更新。
回答你的第二个问题，直接从其他服务访问一个服务的数据库绝不是一种选择，这将导致这两个服务将耦合到同一个数据库，因此客户服务将无法根据它自己的需求，因为其他服务知道并依赖于数据库结构（表、列、关系......等）。这里的解决方案是，如果您需要的数据与流程没有直接关系，或者没有性能强的要求，您可以在每次需要信息时查询服务。
但是，如果信息是其他服务流程的一部分，或者需要高性能，那么最好的解决方案是拥有该信息的本地副本，正如我之前在谈论订单和发票客户时所说的那样，并在任何时候更新它们进行了更改。如果没有事件驱动的方法，这甚至可以是一个缓存。
【讨论】：