问题描述
我正在研究开发一个域明确定义的系统（主要是基于Web的系统）。
I'm looking at developing a system (primarily web based) that has a clearly defined domain.
域的一部分包括诸如日记，预订，客户，等等。
Parts of the domain include entities like Diary, Booking, Customer, etc.
但是，我创建了另一个名为 User 的实体，该实体仅用于身份验证和授权（污染 Customer 实体，其中包含特定于身份验证的数据）。我认为这不属于进行预订的领域，但是具体来说，它应该属于应用程序层（我正在试用六角形体系结构）。
However I created another entity called User whose intention is for authentication and authorization only (it seemed wrong to contaminate the Customer entity with data specific to authentication). I figure this isn't part of the domain of "making bookings", but specifically this should belong to the application layer (I'm trialling a hexagonal architecture).
我正在使用域模型中的接口访问存储库，并使用IoC将其连接到持久层。
I'm accessing my repositories using interfaces in my domain model and wiring them up to my persistence layer using IoC.
我的问题是：
-
我应该将身份验证/授权代码放在应用程序
中，并将其保留在域外吗？
Should I put the authentication/authorization code in the applicationand keep it out of the domain?
如果我确实将其保留在域外，是否应该在应用程序层中将
UserRepository 的界面也放在应用层中（我认为
会有意义）吗？
If I do keep it out of the domain, should I put the interface for theUserRepository in the application layer also (I think this wouldmake sense)?
如果我确实将其排除在域外，那么在应用程序中最终也会得到实体层称为 User 等。这似乎是错误的。
If I do keep it out of the domain, I will end up with entities also in the application layer called User etc. This seems wrong.
什么是人们的想法吗？
我去了需要一点点的解决方案来自两个答案，因此感谢您的回答，我已经为您+1。
I've gone for a solution that takes a bit from both answers, so thanks for answering and I've +1'd you both.
我所做的就是将身份验证/授权代码放在子域中（辅助适配器），因为它需要访问自己的持久性（一个单独的RavenDB数据库中的一些集合），因此我将它们直接包含在单独的项目中，以使它们与主持久性层分离。 p>
What I've done is put the authentication/authorisation code in a subdomain (secondary adapter), in a separate project, and because it requires access to it's own persistence (a few collections in a separate RavenDB database), I'm including these straight into the separate project keeping them separate from the main persistence layer.
推荐答案
否，您应该将身份验证/授权代码保留在核心域之外。它属于一个通用子域。
No, you should keep authentication/authorization code out of the core domain. It belongs to a generic subdomain.
您可以将UserRepository保留在域层中，但最好将访问和识别子域与进行预订核心域彼此分开。您可以使用其他包或名称空间。
You could keep UserRepository in the domain layer, but you'd better keep the "access and identify" subdomain and the "making bookings" core domain separated with each other. You could use different packages or namespace.
下一个挑战是如何集成这两个域。以我的拙见，您可能会：
The next challenge is how to integrate these two domains. In my humble opinion, you may:
- 将DomainService从访问和标识子域暴露给应用程序层，以进行身份验证/授权决策
- 有时我们必须找出谁制作了日记和预订，在这种情况下，使用用户的标识符就足够了。在进行预订核心域中通常不需要等其他信息，例如收藏夹标签或类似信息。
- Expose a DomainService from "access and identify" subdomain to the application layer for making authentication/authorization decisions.
- Sometimes we have to find out who made Diaries and Bookings, in this case, use the identifier of the User is enough. Other information such as "favorite tags" or something like that is usually not needed in "making booking" core domain.
这篇关于身份验证和用户任务的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！