身份验证和用户任务

Question

我正在研究开发一个有明确定义域名的系统（主要是基于网络）。

域的某些部分包括Diary，Booking，Customer等实体。

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

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

我的问题是：

• 我应该将身份验证/授权代码放在应用程序中吗？ 并将其排除在域外？

• 如果我确实将其保留在域外，我应该将接口用于 应用程序层中的UserRepository也是（我想这会 有意义吗？

• 如果我确实将其保留在域外，我最终会在名为User等的应用程序层中使用实体。这似乎是错误的。

人们的想法是什么？

[编辑]

我已经找到了一个解决方案，从两个答案都需要一点点，所以谢谢你回答，我已经给你们两个+1了。

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

Answer 1

身份验证是一个通用域，而不是域的一部分。所以，是的，将它保存在应用层的某个组件中。

并非系统的所有部分都应遵循DDD模式。如果您看到了这方面的好处，您可以使用UserRepository，但我会使用您的环境中的一些已经可用的组件/流行库，如ASP.NET世界中的MembershipProvider。

Answer 2

  

我应该将身份验证/授权代码放在应用程序中吗？   并将其排除在域外？

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

  

如果我确实将其保留在域之外，我应该将接口用于   应用程序层中的UserRepository也是（我认为这会使   义）？

您可以将UserRepository保留在域层中，但最好保持“访问和识别”子域和“制作预订”核心域相互分离。您可以使用不同的包或命名空间。

下一个挑战是如何整合这两个领域。以我的拙见，你可以：

1. 将DomainService从“访问并识别”子域暴露给应用层，以进行身份​​验证/授权决策。
2. 有时我们必须找出谁制作了日记和预订，在这种情况下，使用用户的标识就足够了。其他信息，例如“最喜欢的标签”或类似内容，在“预订”核心域名中通常需要不。