我有一个六边形架构的服务，负责在系统中创建潜在客户。在这个服务中我没有用户，我必须调用外部服务。
在我通过 API 收到的潜在客户创建请求中，我没有 user_id（创建者），我有用户电子邮件。
我的问题是，我应该在哪里打这个电话？
a) 在控制器中调用外部服务来获取用户，并将其传递给负责创建潜在客户的应用程序服务。在这种情况下，我是否应该再次调用外部服务来检查给定的 ID 是否存在？
b) 在控制器中，传递电子邮件，并在应用程序服务中使用用户电子邮件调用外部服务，以获取用户。
我更喜欢第一个，因为我不会因为我在 API 中收到的内容而损害应用程序服务。
你怎么看？
【问题讨论】：
标签： domain-driven-design hexagonal-architecture
我假设由于您附加了 domain-driven-design 标签，因此您遵守 DDD 战术模式，我的意思是您有一个您正在尝试在此处创建的 DDD 潜在客户相关实体。
在这里扩展几点很有用。
首先，为了解决您的问题，在六边形架构中，“端口和适配器”模式非常普遍，几乎可以说是同义词。在端口和适配器中，对于输入，您将有一个端口接受外部请求并将其转换为内部理解的通用语言，然后再将其传递到域/业务逻辑代码中。在这种模式中，API 控制器可以很好地被视为一个端口，它可以通过检索 VO 需要的数据并将请求转换为内部值对象（以下简称 VO），并在其创建合约中公开。这意味着控制器将获取填充有效 VO 以表示必要的域对象（潜在客户来源、客户，无论您拥有什么）所需的所有数据。
不过，我想提出的一个考虑是，这意味着缺少此服务履行其职责所需的数据。视情况而定，这可能不是问题，但如果这些是分布式服务，则您将此服务的可用性与其他服务（拥有用户）的可用性联系起来。你有几个选择：
【讨论】：
因为依赖在六边形架构中向内流动，所以控制器应该依赖于：
作为编排器，控制器应执行以下功能：
无需使用来自其他“接口”的依赖项来破坏 Lead App Service。由于 Lead App Service 定义了它需要 User Id，因此应该由控制器来编排从 User Identity App Service 中检索 User Id 的过程以及它可用的上下文信息。
【讨论】：