domain-driven-design - Onion 架构中的服务和授权

Question

我正在尝试学习洋葱架构，据我所知，我将我的解决方案组织如下:

领域

Domain.Entities(业务对象)

Domain.Interfaces(域服务和存储库的接口(interface))

Domain.Services(域服务接口(interface)的实现)

基础设施

Infrastructure.Data(使用 EF 实现存储库和工作单元)

Infrastructure.DependencyResolution(使用 Unity 实现 IoC)

用户界面

UI.WebMVC

这是我的问题:

1-我对这些层是正确的还是我错过了什么？

2- 至于与特定技术相关的服务(例如日志记录)，它们的接口(interface)应该在哪里(Domain.Interfaces 或 Infrastructure.Interfaces)？

3- 据我了解，域服务将处理我的业务用例，那么我将从应用程序服务中获得什么好处

4-域服务和应用服务有什么区别，应用服务接口(interface)应该在哪个项目中？

5- 用户授权过程应该是应用程序服务或域服务的一部分吗？

Answer 1

这是六边形架构的架构，但它非常接近洋葱和 IMO，您应该使用它。这里显示了 3 层:域(黄色)、应用程序(红色)、基础设施(绿色 + 蓝色)。所以回答你的问题 - 你缺少一些像应用程序服务这样的部分。

日志记录可能不是您的域逻辑的一部分，因此它应该在基础设施中，包括接口(interface)和实现。要使用它，您必须将其注入(inject)您的应用程序层。

域服务只处理与您的业务相关的事情。应用程序服务大部分时间都在为领域服务做准备，例如创建存储库并从中检索聚合，然后调用领域服务并将聚合传递到那里。你不应该在应用层处理你的业务逻辑!

正如我在第 3 点中所写的那样。应用程序服务应该在每个使用域服务的项目中。

依靠。用户使用用户凭据请求您的基础设施层，基础设施层使用该凭据调用应用程序层，您尝试使用给定凭据检索用户，但首先您将原始密码转换为具有某些功能的散列密码。如果找到用户，您可以在基础设施层对用户进行身份验证。这里不需要域服务，但它是一个异常(exception)。