domain-driven-design - 六边形架构在控制器或服务中聚合

Question

我有一个六边形架构的服务，负责在系统中创建潜在客户。在此服务中，我没有用户，我必须调用外部服务。

在我通过 API 收到的潜在客户创建请求中，我没有 user_id（创建者），我有用户电子邮件。

我的问题是，我应该在哪里打这个电话？

a) 在控制器中调用外部服务来获取用户，并将其传递给负责创建线索的应用程序服务。在这种情况下，我是否应该再次调用外部服务来检查给定的 ID 是否存在？

b) 在控制器中，传递电子邮件，并在应用服务中使用用户电子邮件调用外部服务，以获取用户。

我更喜欢第一个，因为我不会用我在 API 中收到的内容来损害应用程序服务。

你怎么看？

标签： domain-driven-designhexagonal-architecture

Answer 1

我假设既然您附加了domain-driven-design您遵守 DDD 战术模式的标签，我的意思是您有一个您正在尝试在此处创建的 DDD 潜在客户相关实体。

在这里扩展几点很有用。

首先，为了解决您的问题，在六边形架构中，“端口和适配器”模式非常普遍，几乎是同义词。在端口和适配器中，对于输入，您将有一个端口，它接受外部请求并将其转换为内部理解的通用语言，然后再将其传递到域/业务逻辑代码中。在这种模式中，API 控制器可以很好地被视为一个端口，它可以通过检索 VO 需要的数据并将请求转换为内部值对象（以下简称 VO），并在其创建合约中公开。这意味着控制器将获取填充有效 VO 以表示必要的域对象（潜在客户、客户，无论您拥有什么）所需的所有数据。

不过，我想提出的一个考虑是，这意味着缺少该服务履行其职责所必需的数据。视情况而定，这可能不是问题，但如果这些是分布式服务，则您将此服务的可用性与其他服务（拥有用户）的可用性联系在一起。你有几个选择：

1. 一个可能更好的选择（但并不总是取决于一致性要求）可能是观察事件并保存您需要的数据的本地缓存副本，或者可能重新评估服务边界。
2. 另一个（如果您可以这样做，可能是更好的选择）是更改 API 的合同以要求执行此操作所需的任何和所有必要数据。