.net - 构建你的领域对象？

Question

我正在尝试学习领域驱动设计，所以我确信这将是许多问题中的第一个(我已经可以想到至少几个，但我不想分散我的问题)。我正在使用 Dino Esposito 的“为企业构建 Microsoft .NET 解决方案”，在某些情况下，它非常抽象。

首先，我总是假设您的业务对象将具有某种类型的连接(通过构造函数传入)，无论它是存储库还是 DBConnection 或其他。看来我错了。

您是否只是通过传入所有数据的组合以及底层集合(Order-->OrderDetails)的一些添加/删除函数来构造域对象？因此，在您的 DataMapper 中，您将从数据库中的元组构造业务对象，然后通过您将使用它们的存储库将它们返回到应用程序层？然后，您的应用程序层和 DL 都需要对您的业务对象的引用。如果您不使用 ORM 或者即使您使用 ORM，这当然会迫使您构建自己的延迟加载机制，因为此时您将断开连接。当然，您不希望在所有情况下都加载所有基础数​​据。

Answer 1

根据域驱动设计 - 域对象是持久性无知的。这意味着 - 它们不应该包含连接到数据库的基础设施代码。但是 - 存储库抽象被视为域模型的一部分。因此 - “允许”使用这些，但我个人喜欢避免这种情况。

如果您正在谈论域对象的建模-那么不，将它们建模为愚蠢的数据包通常不是一件好事。这导致 anemic model .

如果您正在谈论从持久性机制中检索域对象时重建域对象，那么是的 - 基本上这只是从头开始重建域对象。但这里棘手的部分是 - 这种重建和其他与持久性相关的问题不应侵入您的域。你不应该有没有任何验证的公共(public)添加/删除功能，只是为了让你的持久性工作。在现实中 - 很难保持模型完全干净(事实上，它已经与你正在使用的编程语言搞砸了，除了现实之外，不存在可以容纳它的纯媒介，你正在建模自己)并且总会有一些隐式依赖(例如 - 使用 NHibernate ORM 时必须将所有内容标记为虚拟)。

但是如果您想了解领域驱动设计，您并没有关注您应该做什么。领域驱动设计的核心是无处不在的语言和明确建模的业务。这是关于你的方式想 .从阅读开始'blue book' .两次。看看这个sample application通过 Szymon Pobiega 直到你 明白原因在这些代码行后面。

编辑:哦...忘了ddd yahoo group这也是很好的信息来源。

One thing that confuses me in your post is about you shouldn't "Model" them as dumb property bags but in "reconstructing" then its ok.

看看这个(过于简单和糟糕的)例子。从客户端，除非您在作弊，否则您将无法创建 name.Length>50 的新 Person。

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);

It sounds like its a very complex topic and probably a lot of people who think the are using domain-driven design..aren't

一开始的领域驱动设计确实令人困惑。最糟糕的事情可能发生(并且通常发生)是当开发人员开始 相信不知从何而来 he is doing it right (我自己去过那里。可能我还在那里):

And... is the Domain-Driven Design used in .NET pop culture really Domain-Driven Design in fact

这会导致很多困惑和错误。 Some试着解释一下 why .有些只是 hate它。