身份验证和用户任务

Adr*_*ips 5 domain-driven-design

我正在考虑开发一个具有明确定义域的系统(主要是基于 Web 的)。

域的配件包括实体,如DiaryBookingCustomer,等。

但是,我创建了另一个名为User的实体,其意图仅用于身份验证和授权(Customer用特定于身份验证的数据污染实体似乎是错误的)。我认为这不是“预订”领域的一部分,但具体来说这应该属于应用层(我正在试用六边形架构)。

我正在使用域模型中的接口访问我的存储库,并使用 IoC 将它们连接到我的持久层。

我的问题是这样的:

  • 我应该将身份验证/授权代码放在应用程序中并将其保留在域之外吗?

  • 如果我确实将它排除在域之外,我是否也应该将 的接口 UserRepository也放在应用程序层中(我认为这是有道理的)?

  • 如果我确实将它排除在域之外,我最终也会在应用程序层中使用称为User等的实体。这似乎是错误的。

人们的想法是什么?

[编辑]

我已经找到了一个从两个答案中都需要一点的解决方案,所以感谢您的回答,我已经对你们两个都+1了。

我所做的是将身份验证/授权代码放在一个子域(辅助适配器)中,在一个单独的项目中,并且因为它需要访问它自己的持久性(一个单独的 RavenDB 数据库中的一些集合),我包括这些直接进入单独的项目,使它们与主持久层分开。

Yug*_*hou 4

我应该将身份验证/授权代码放在应用程序中并将其保留在域之外吗?

不,您应该将身份验证/授权代码保留在核心域之外。它属于通用子域。

如果我确实将其保留在域之外,是否也应该将 UserRepository 的接口放在应用程序层中(我认为这是有意义的)?

您可以将 UserRepository 保留在域层中,但最好将“访问和识别”子域和“进行预订”核心域彼此分开。您可以使用不同的包或命名空间。

下一个挑战是如何整合这两个领域。以我的愚见,您可以:

  1. 将 DomainService 从“访问和识别”子域公开到应用程序层以做出身份验证/授权决策。
  2. 有时我们必须找出谁进行了日记和预订,在这种情况下,使用用户的标识符就足够了。在“进行预订”核心域中通常不需要诸如“最喜欢的标签”或类似的信息之类的其他信息。