BFF（后端用于前端）和 DDD 是互斥的吗？

Question

BFF 模式提供了一个集成所有微服务的 API（对于某些前端）。

就我而言，我有 BFF 额外负责用户身份验证。我的 BFF 项目使用 Clean Architecture。

我的微服务之一是

Conversations

服务。它为我提供了一些用户开始聊天的人、他们发送的消息等信息。

使用使用 Clean Architecture 的 BFF 集成微服务时会出现问题，因为我的 BFF 负责身份验证。

我有

User

域实体，可能如下所示：

public class User
{
    public string Id { get; set; }
    public string Name { get; set; }
    public AvatarUrl AvatarUrl { get; set; }
}

所以我想在我的 BFF 中创建端点，从经过身份验证的 cookie 检索用户信息。看起来很简单。可是等等。我的BFF集成了微服务，我构建了聊天应用程序，因此用户所属的对话也是用户信息。

所以我们需要考虑我的BFF的域是什么？仅限于BFF在本地执行的操作（身份验证），还是代理也是域（微服务）？我的意思是，我的

User

还应该包含

Conversations

属性（对话列表）吗？领域实体可以依赖外部服务吗？

或者也许没有 BFF 的领域（因为它集成了微服务并且自己几乎不做任何事情），而这里的 DDD 只是多余的？

Answer 1

我一直认为 BFF 是一个破损的软件设计。

你最好的朋友实际上应该是你设计的界面的领域模型。

因此，BFF 不仅仅充当调用业务逻辑并将业务逻辑委托给其他服务的事务脚本。想象一下以下情况：

您有一个客户请求更改您交付的应用程序上的域逻辑，那么您将做什么，更改 BFF 和包含业务逻辑的服务？这是纯粹的开销，我也看到开发人员将特定的域模型放入 BFF 中，因为它是特定于他们的应用程序的。

最好在 BFF 中完成所有 DDD，如果您需要通用子域，它们是建模为通用/支持有界上下文的良好候选者。

我还没有真正回答这个问题，因为我在 BFF 上也遇到了同样的困难，我的建议是不要使用它们，而是编写适当的 DDD 有界上下文，其中接口层是 REST 资源。

假设您有六边形架构，您仍然有 4 层：

简而言之，你的BFF驻留在资源下的端口适配器部分。