-1

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

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

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

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

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

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

你怎么看？

4

2 回答 2

2

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

在这里扩展几点很有用。

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

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

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

因为依赖关系在六边形架构中向内流动，所以控制器应该依赖于：

  • 用户身份应用服务接口
  • 主导应用服务接口

作为编排器，控制器应执行以下功能：

  • 识别用户
  • 创建潜在客户

无需使用来自其他“接口”的依赖项来破坏 Lead App Service。由于 Lead App Service 定义了它需要 User Id，因此应该由控制器来编排从 User Identity App Service 中检索 User Id 的过程以及它可用的上下文信息。

于 2020-02-28T23:03:51.970 回答