Domain driven design 六边形体系结构在控制器或服务中聚合

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

在我通过API收到的lead create请求中，我没有用户id（创建者），我有用户电子邮件

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

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

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

我更喜欢第一个，因为我不会因为API中的内容而影响应用程序服务

---

你觉得怎么样？

我假设，既然你附加了

领域驱动设计

标签，你就坚持DDD战术模式，我的意思是你有一个DDD领导相关的实体，你正在尝试在这里创建

在这里展开几点很有用

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

但我想提出的一个考虑因素是，这意味着缺少此服务履行其职责所需的数据。根据具体情况，这可能不是问题，但如果这些是分布式服务，则您将此服务的可用性与其他服务（拥有用户）的可用性捆绑在一起。您在这里有几个选项：

一个可能更好的选择（但并不总是取决于一致性要求）可能是观察事件并保存所需数据的本地缓存副本，或者可能重新评估服务边界

另一个（如果可以这样做，可能更好的选择）是更改API的契约，以要求执行此操作所需的所有必要数据

---

由于依赖项在六边形体系结构中向内流动，控制器应依赖于：

• 用户身份应用程序服务接口
• Lead应用程序服务接口

作为协调器，控制器应执行以下功能：

• 识别用户
• 创造领先优势

没有必要用来自其他“接口”的依赖关系来损害Lead App服务。由于Lead App服务定义它需要用户Id，因此应由控制器使用其可用的上下文信息协调从User Identity App服务检索用户Id的过程