如何用域驱动设计来设计系统？

Question

我想问一个更具哲学意义的问题。主题是DDD和微服务。DDD可以识别有界上下文。如果我理解正确的话，那么每个有界上下文都是整个系统的一小部分。例如，可能存在排序上下文和发票上下文。每个上下文都与客户一起工作，但订购上下文不能知道开票设置，发票不能知道订购设置。这是否意味着将有两个客户微服务，每个服务用于每个上下文？第二个问题是:如果我有订单微服务，我可以加载客户数据来评估一些条件，检查客户是否可以直接从数据库创建新订单，或者我是否需要通过客户微服务访问？

谢谢你的意见。

Answer 1

首先，你必须知道，相同的概念在不同的上下文中可能意味着不同的东西。例如，在订单上下文中，实体客户可能意味着您可以交付物品的人，因此订单客户将具有地址、首选交付时间等属性。等。

然而，如果我们在发票上下文中查看客户，它将意味着您可以获得付款的人，因此它将具有信用卡号、paypal帐户、首选支付类型等属性。

在事件驱动的设计中，此实体将通过暂停更新客户事件来根据服务上下文进行更新，因此当产生对交付或支付选项的任何修改时，此实体将更新。

回答你的第二个问题，直接从另一个服务访问一个服务的数据库永远不是一个选择，这将导致两个服务耦合到同一个数据库，因此客户服务将无法根据自己的需要管理其数据库，因为其他服务知道并依赖于数据库结构(表、列、关系)。等)。这里的解决方案是，如果您需要的数据与流程没有直接关系，或者如果没有强大的性能需求，您可以在每次需要信息时查询服务。

但是，如果信息是其他服务流程的一部分，或者需要高性能，最好的解决方案是拥有该信息的本地副本，就像我之前在谈论订单和发票客户时所说的那样，并在发生任何更改时更新它们。如果没有事件驱动的方法，这甚至可以是一个缓存。