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

Question

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

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

我很困惑,要做出决定.

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

任何帮助都会很明显.

Answer 1

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

看起来您将域模型视为一个单一的模型,您可以将每个应用程序放入其中.相反,请专注于战略模式以区分有界上下文.将域视为几个松散互连组件的组合.然后确定您的核心域名是什么,并在那里应用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用户并生成相应的有界上下文的用户.

Answer 2

您可以使用任何您喜欢的东西。但要注意特定解决方案将产生的污染。如果您的域模型被数百行 ASP.NET 技术类型的管道代码搞乱了，这会使您的域逻辑难以感知，并且您错过了 DDD 的要点。

在理想情况下 - 您的领域模型应该仅依赖于编程语言。

另外，您可能会从我很久以前实现的用户会话相关代码中发现一些有用的东西。