我正在研究将端口和适配器模式与分层架构一起使用。
所以我将有以下几层:
- 框架/基础架构 - 即 ASP.NET MVC、实体框架、SMTP 客户端
- 应用程序 - 将您的应用程序拉到一起并在您的域上执行操作的逻辑。
- 域 - 定义域中的操作如何工作。定义域对象之间的关系
在阅读了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));
}
}
对我来说,这似乎很糟糕,因为现在您已经强制框架层进行验证,这应该是域逻辑的一部分(因为我们停在应用程序层,甚至没有机会这样做)。这也意味着应用程序层实际上并没有将业务逻辑拉在一起......它只是说明它想要完成的操作,但让调用者决定如何做。应该反过来吧?
概括
我知道我说了很多,所以让我总结一下……驱动程序端口和适配器如何工作?在现实世界的场景中应该如何使用/实施它们?