C# 在域模型中，将特定于技术的东西放在何处？

我们有一个应用程序，它与许多事情一起对Active Directory进行一些更改（从组中添加/删除用户，更改用户的属性值，等等）

我们现在正在重新设计它（从“意大利面代码”到更分层的解决方案）。Active Directory管理功能在某种程度上是我们希望在域层抽象出来的，但同时，大多数功能都非常依赖于技术

我们应该将所有Active Directory访问代码与DB访问一起放在数据访问层中，还是可以创建一个Active Directory函数库并直接从域模型调用该库？这会使域对象持久化，这可能是个坏主意

---

或者所有Active Directory访问都应该在服务层执行，甚至不涉及域层吗？

我认为特定于技术的内容是实现细节，不应该放在域模型中。

域模型应该是技术不可知的，所以不要把你的广告代码放在域模型中

实际上，您可以说AD代码只是数据访问的另一种形式，因此它属于数据访问层（DAL）。然而，它不属于您的数据库模块，因为这将违反（SRP-它适用于模块以及单个类型）

与其将其与数据库访问捆绑在一起，不如在其自己的库中实现它。从概念上讲，它属于同一层，但做的事情不同，因此现在在同一层中有两个库。这非常好-您可以根据需要在每个层中拥有任意多的库

在域模型中，将AD访问（和DB访问）视为抽象。抽象存储库是默认方法。AD库将包含AD存储库的实现，DB库将包含DB存储库的实现

这非常符合反腐败层的概念

---

您可以使用依赖项注入（DI）将具体的存储库与您的域模型连接起来。

那么您的意思是应该将其放在服务层中？或者你建议它应该放在哪里？我对领域模型还不熟悉（已经阅读了很多关于这个主题的文章和书籍，但仍然感觉不太舒服；）…这是有道理的。因此，你的意思是我应该在我的域层中为用户、组等创建域对象，并通过使用类似虚拟代理模式的方式，向我的域对象添加特定于技术的关注点（如组添加/从用户中删除）？如果用户和组在上下文中有意义，请将它们放在域模型中（它们可能会这样做）。不过，不需要虚拟代理，因为所有域对象都应该是POCO。存储库只是公开允许您从基础存储中检索或修改域对象的方法。您的意思是域对象应该知道存储库吗？我在这里绞尽脑汁，但我无法清楚地了解如何正确实现域模型…；）。关于域模型应该如何实现，似乎有很多观点（或者我只是误解了它们）。我希望有人能在设计时握住我的手……）知道存储库的域对象正在使用活动记录模式，但这种模式目前并不流行。我更喜欢持久无知的POCO，这意味着存储库知道域对象，而不是相反。请看一下Jeremy Miller在MSDN杂志上的概述文章：