我们可以在域驱动设计中使用ASP.NET标识吗？

我们的团队决定将Domain Driven Design架构用于我们的项目.现在正在进行讨论," 我们可以在DDD中使用ASP.NET身份吗？".

在DDD设计中使用ASP.NET标识是否有任何缺点.

我很困惑,要做出决定.

我已经搜索过了,但我没有想到.

任何帮助都会很明显.

这些问题揭示了一些误解:

看起来您将域模型视为一个单一的模型,您可以将每个应用程序放入其中.相反,请专注于战略模式以区分有界上下文.将域视为几个松散互连组件的组合.然后确定您的核心域名是什么,并在那里应用DDD战术模式.并非每个ccomponent都需要DDD.其中一些人甚至不应该使用DDD.特别是 - 通用域,如身份验证.

DDD是技术不可知的(在某些方面)所以是的,你可以使用ASP.NET Identity或任何你喜欢的库.

身份验证通常属于Application层,而不属于Domain层.

但是 - 如果在您的域中存在用户/客户端/人的概念,则可能需要使用身份组件提供的身份.但是你必须明白,有界上下文中User的含义与Identity in Identity中的含义不同.这些概念不一样.虽然他们都指的是坐在某个地方并点击应用程序GUI的同一个身体的人,但他们是2个不同的模型(或投影),用于不同的目的.因此,您不应该仅仅在有界上下文中重用ASP.NET User类.

相反 - 单独的上下文应该通过反腐败层进行通信.基本上,您必须在有界上下文中创建一些服务(仅限接口),以生成特定于上下文的User对象.在基础结构层中实现的该接口的实现将是ASP.NET Identity的包装,它获取ASP.NET Identity用户并生成相应的有界上下文的用户.