时间戳

首页 > 解决方案 > 六边形架构：如何实现驱动程序端口

architecture - 六边形架构：如何实现驱动程序端口

问题描述

我正在研究将端口和适配器模式与分层架构一起使用。

所以我将有以下几层：

在阅读了https://softwarecampament.wordpress.com/portsadapters/#tc2-3、https://fideloper.com/hexagonal-architecture和其他几篇文章以及多个 youtube 讲座后，我仍在努力解决如何实现驱动程序端口和适配器。我理解驱动端口和适配器的想法，因为这是我使用普通分层架构所做的事情。

但我仍然不明白如何实现驱动程序端口和适配器。

据我了解，驱动程序端口定义了它外部的层应该使用它所在的层的方式。适配器是该端口在使用该端口的层上的实现。

但是我正在努力解决一些问题......应用程序层如何实现与域层的接口？那不是要求应用层知道领域层的相互作用吗？这完全破坏了首先使用界面的意义。如果领域层提供了一个外部的东西应该使用的接口，并且该接口的适配器是由使用该接口的层实现的，这意味着该接口的用户也在实现该接口本身。就像外部层告诉内部层如何工作......这违背了解耦甚至一般接口的本质。

听起来业务层正在告诉应用层，“这是我提供给你的接口...... IDK 它将如何工作，所以你告诉我。” 但是，为什么一开始还要有界面呢？

这是一些代码来演示我正在描绘的内容：

applicationLayer.UserRegisteringUseCasePort

public interface UserRegisteringUseCasePort
{
    void Register(string username, string password, string passwordConfirm, string name);
}

frameworkLayer.UserRegisteringUseCaseAdapter

public class UserRegisteringUseCaseAdapter : UserRegisteringUseCasePort
{
    private IUserRepository _userRepo;

    public class UserRegisteringUseCaseAdapter(IUserRepository userRepo)
    {
        _userRepo = userRepo;
    }

    public void Register(string username, string password, string passwordConfirm, string name)
    {
        // validation logic
        //... such as:
        if (password != passwordConfirm) {
            throw new Exception("password no match password confirm!");
        }
        userRepo.Add(new User(username, password, name));
    }
}

对我来说，这似乎很糟糕，因为现在您已经强制框架层进行验证，这应该是域逻辑的一部分（因为我们停在应用程序层，甚至没有机会这样做）。这也意味着应用程序层实际上并没有将业务逻辑拉在一起......它只是说明它想要完成的操作，但让调用者决定如何做。应该反过来吧？

概括

我知道我说了很多，所以让我总结一下……驱动程序端口和适配器如何工作？在现实世界的场景中应该如何使用/实施它们？

标签： architecturehexagonal-architecture

解决方案

驱动程序端口和适配器如何工作？在现实世界的场景中应该如何使用/实施它们？

驱动程序端口是“应用程序”的 API（在 HexArch 术语中，应用程序是整个六边形，不要与应用程序层混淆）。它们向外界提供应用程序的功能（用例、用户故事或任何你称之为的东西）。

驱动适配器不实现驱动端口。这是很多人都会犯的错误。驱动程序适配器是应用程序外部使用驱动程序端口的软件组件。驱动程序端口是驱动程序适配器的依赖项。驱动适配器示例：MVC Web 控制器、REST 控制器、自动化测试框架等

驱动程序端口的实现是应用程序本身的业务逻辑。它是用例实现。在您的情况下，您将六边形分成两层：应用层和域。那么驱动程序端口的实现将是一个应用程序服务实现，它编排域对象以执行用例功能。

希望我的解释有所帮助。

推荐阅读