我正在尝试学习领域驱动设计，所以我确信这将是许多问题中的第一个（我已经可以想到至少还有一些问题，但我不想分解我的问题）。我正在使用Dino Esposito的“为企业架构Microsoft .NET解决方案”，在某些情况下，它非常抽象。
首先，我总是假设您的业务对象将具有某种类型的连接（通过构造函数传入），无论它是存储库还是DBConnection或其他什么。看起来我错了。
您是通过传递所有数据的组合构建域对象，也可能是基础集合的一些添加/删除函数（Order - ＆gt; OrderDetails）？那么在您的DataMapper中，您将从数据库中的元组构造商业对象，然后通过存储库将它们返回到应用程序层，您将使用它们？然后是你的应用层和DL需要引用您的Business对象。如果您不使用ORM，或者即使您使用ORM，这当然会强迫您构建自己的延迟加载机制，因为此时您将断开连接。当然，您不希望在所有情况下加载所有基础数据。
答案 0 :(得分：3)
根据域驱动设计 - 域对象是持久性无知的。这意味着 - 它们不应包含连接到数据库的基础结构代码。但是 - 存储库抽象被视为域模型的一部分。因此 - “允许”使用它们，但我个人希望避免这种情况。
如果您正在谈论域对象的建模 - 那么不，主要是将它们建模为哑数据包并不是一件好事。这导致anemic model。
如果您正在谈论从持久性机制中检索域对象时重构域对象，那么是 - 基本上这只是从头开始重建域对象。但这里棘手的部分是 - 这个重建和其他持久性相关的问题不应该侵入你的域。您不应该在没有任何验证的情况下使用公共添加/删除功能，只是为了使您的持久性能够正常工作。实际上 - 很难保持模型完全干净（事实上，它已经搞乱了你正在使用的编程语言，并且不存在可以容纳它的纯媒体，除了现实你正在建模本身）并且总会存在一些隐式依赖（例如 - 使用NHibernate ORM时，所有内容都必须标记为虚拟）。
但是，如果您想了解域驱动设计，那么您并没有专注于应该做的事情。领域驱动设计的核心是语言无处不在，并明确建模业务。这是你思考的方式。首先阅读'blue book'。两次。并查看Szymon Pobiega的sample application，直到您理解这些代码行背后的 。
编辑：哦......忘了ddd yahoo group这也是非常好的信息来源。有一件事让我感到困惑的是你不应该把它们“塑造”为愚蠢的财产袋，而是“重建”然后它的确定。
看看这个（过于简单和不好的）示例。从客户端来看，除非您作弊，否则您将无法创建名称为.Length> 50的新人。
public class Person{
public Person(string name){
if (name.Length>50) throw new ArgumentException
("Person name length should not exceed 50 characters");
Name=name;
}
public string Name {get;private set;}
}
但是当我们从持久性机制重建对象时 - 作弊正是我们所做的。我们绕过验证，我们直接设置数据，我们绕过对象行为，因为数据代表状态。例如。使用反射：
typeof(Partner).GetProperty("Name").SetValue(partner,nameFromDB);
这听起来像是一个非常复杂的主题，可能很多人认为使用域驱动设计......不是
开始时的域驱动设计确实令人困惑。最糟糕的事情是，当开发人员开始相信无处不在时he is doing it right（我自己也在那里。可能我还在那里）：
并且......是.NET流行文化中使用的领域驱动设计实际上是域驱动设计