有丰富的领域模型示例吗？

Question

Closed. This question is seeking recommendations for software libraries, tutorials, tools, books, or other off-site resources. It does not meet Stack Overflow guidelines. It is not currently accepting answers.

---

我们不允许提出寻求软件库、教程、工具、书籍或其他场外资源推荐的问题。您可以编辑问题，以便用事实和引文来回答。

4 年前已关闭。

Answer 1

我会给你一个真实生产代码的简单示例：

Person.groovy:

  List addToGroup(Group group) {
    Membership.link(this, group)
    return groups()
  }

Membership.groovy:

 static Membership link(person, group) {
    def m = Membership.findByPersonAndGroup(person, group)
    if (!m) {
        m = new Membership()
        person?.addToMemberships(m)
        group?.addToMemberships(m)
        m.save()
    }
    return m
}

每当我想将一个人绑定到一个组时，我可以这样做person.addToGroup(group)

在你的控制器上，程序代码将是这样的：

def m = Membership.findByPersonAndGroup(person, group)
 if (!m) {
        m = new Membership()
        person?.addToMemberships(m)
        group?.addToMemberships(m)
        m.save()
}

乍一看，你可以说你可以将其包装在一个函数中，然后就可以开始了。
但恕我直言，富域设计的优点是它更接近你的思维方式，从而更接近合理化。在这个特定的示例中，我只想将一个人添加到一个组中，代码将读取该内容。

正如您所要求的，这是一个简短的示例，但是很容易扩展此示例并看到您可以使用适当的域建模来构建复杂的交互。

您还可以查看 Martin Fowler 的 交易脚本 与 Domain Model 简要解释了这两种模式，我认为它们与 DDD 相关。

Answer 2

我认为没有人做过这样的比较，如果有的话，那么它的影响也不会小。领域驱动设计试图解决复杂性，而简单的示例并不包含复杂性。

也许领域驱动设计分步会给你一些答案。

Answer 3

这并不能完全回答您的问题，但我认为领域驱动设计与数据库驱动设计相反。在数据库驱动设计中，首先创建数据库模式，然后在充分了解该模式的情况下创建类。优点是您可以更好地了解“幕后”发生的情况，并最大限度地减少阻抗不匹配的影响。然而，缺点是数据库模式，因为它是关系型的而不是面向对象的，所以不能很好地转换为对象（例如，关系数据库中没有集合的概念）。

在领域驱动设计中，理论上，您可以像创建任何其他类一样创建数据对象，并将数据库视为简单的持久层。通俗地说，数据库只是一个存储容器，您不关心对象如何存储，只关心它们以某种方式存储。这消除了阻抗不匹配，您就少了一件需要担心的事情。然而，在实践中，您仍然必须了解对象的存储方式，并且当您使用的 ORM 尝试输出复杂的 SQL 查询时，可能会出现性能问题。

编辑：

这是一个原则上领域驱动设计应该是什么样子的示例。假设您有一个 Person 类，如下所示（在 C# 中）：

public class Person
{
    public int Id { get; set; }
    public string Name { get; set; }
    public Address Address { get; set; }
    public ICollection<Person> Relatives { get; set; }
    public Company Employer { get; set; }
}

现在，在关系数据库中，这可能会转换为 3 个表：Person 表、Address 表和 Company 表，它们之间有一堆关系。然而，这与程序员看待这个对象的方式有很大不同。程序员将其视为具有 4 个参数的 Person 对象的实例，其中之一是 ICollection。这与数据库表结构不太匹配，因此出现“阻抗不匹配”，或者用外行人的话来说，关系模型和对象模型之间的布局差异。

在领域驱动设计中，我应该能够做到这一点：

Person person = new Person();
// set each property to something
Database.Save(person);

现在，人员对象已保存。我可以像这样检索它：

Person databasePerson = Database.Get<Person>(idOfPerson);

它将返回我的 Person 对象，就像我保存它之前一样。这样，我根本不关心数据库如何保存它，也不担心阻抗不匹配。我只是保存它并根据需要检索它。

但这都是理论上的。在实践中，您可能必须手动指定“映射”，或者类如何知道从数据库中的哪个表/列获取数据。当您尝试映射到更复杂的类型（例如字典和其他 ADT）时，以及当您尝试将多个表中的数据提取到一个类中时，它可能会变得相当复杂。