20

我已经阅读了一些关于贫血域模型和关注点分离的问题。在贫血的域对象上执行/附加域逻辑的最佳技术是什么？在我的工作中，我们有一个非常贫乏的模型，我们目前正在使用“帮助器”类来在域对象上执行数据库/业务逻辑。例如：

public class Customer
{
    public string Name {get;set;}
    public string Address {get;set;}
}

public class Product
{
    public string Name {get;set;}
    public decimal Price {get;set;}
}

public class StoreHelper
{
    public void PurchaseProduct(Customer c, Product p)
    {
         // Lookup Customer and Product in db
         // Create records for purchase
         // etc.
    }
}

当应用程序需要进行购买时，它会创建 StoreHelper，并调用域对象上的方法。对我来说，客户/产品知道如何将自己保存到存储库是有意义的，但您可能不希望域对象上的 Save() 方法。对于像 Customer.Purchase(Product) 这样的方法也很有意义，但这会将域逻辑放在实体上。

以下是我遇到的一些技术，不确定哪些是好/坏：

  1. Customer 和 Product 继承自“Entity”类，该类以通用方式提供基本的 CRUD 操作（可能使用 ORM）。
    • 优点：每个数据对象都会自动获取 CRUD 操作，但随后会绑定到数据库/ORM
    • 缺点：这并没有解决对象上的业务操作问题，并且还将所有域对象绑定到可能不合适的基本实体
  2. 使用帮助类来处理 CRUD 操作和业务逻辑
    • 将 DAO 用于“纯数据库”操作是否有意义，而将业务助手用于更特定于业务的操作是否有意义？
    • 为此使用非静态或静态辅助类更好吗？
    • 优点：领域对象不依赖于任何数据库/业务逻辑（完全贫乏）
    • 缺点：不是很面向对象，在应用程序代码中使用助手不是很自然（看起来像 C 代码）
  3. 使用 Double Dispatch 技术，其中实体具有保存到任意存储库的方法
    • 优点：更好的关注点分离
    • 缺点：实体附加了一些额外的逻辑（尽管它是解耦的）
  4. 在 C# 3.0 中，您可以使用扩展方法将 CRUD/业务方法附加到域对象而不接触它
    • 这是一种有效的方法吗？什么是优点/缺点？
  5. 其他技术？

处理此问题的最佳技术是什么？我对 DDD 很陌生（我正在阅读 Evans 的书——所以也许这会让我大开眼界）

4

4 回答 4

15

为了避免贫血模型，重构你的助手类：

类似的逻辑：
“Customer.PurchaseProduct(Product product, Payment payment)”、
“Customer.KillCustomer(Person killer, Weapon weapon)”
应该存在于“Customer”域对象中。

像这样的逻辑：
“Customer.IsCustomerAlive()”
“Customer.IsCustomerHappy()”
应该去规范。

像这样的逻辑：
“Customer.Create()”、
“Customer.Update()”
显然应该去存储库。

像这样的逻辑：
“Customer.SerializeInXml()”
“Customer.GetSerializedCustomerSizeInBytes()”
应该去服务。

复杂的构造器应该去工厂。

我就是这么看的。如果有人能评论我对 DDD 方法的理解，我会很高兴。

编辑：

有时，不应该避免贫血的领域模型。

编辑了我的答案以添加 DDD 不是关于拾取和删除模式。
DDD 是关于我们的思考方式。

于 2009-05-21T13:46:04.607 回答
7

Martin Fowler 写了很多关于领域模型的文章，包括贫血领域模型。他还对可能有用的领域模型和数据库的许多设计模式进行了简要描述（和 UML 类图）：“企业应用程序体系结构模式”目录。

我建议查看Active Record和Data Mapper模式。从您的问题的描述中，听起来您的帮助类包含域/业务规则和数据库实现细节。

Active Record 会将助手的域逻辑和数据库代码移动到其他域对象（如您的Entity基类）中。数据映射器会将助手的域逻辑移动到域对象中，并将数据库代码移动到单独的映射对象中。这两种方法都比过程式辅助类更面向对象。

Eric Evans 的“领域驱动设计”一书非常出色。它有点干，但绝对值得。InfoQ 有一本“Domain Driven Design Quickly”迷你书，它很好地介绍了 Evans 的书。此外，“快速领域驱动设计”以免费 PDF 格式提供。

于 2009-03-07T08:13:37.983 回答
2

我一直认为贫血域模型是一种反模式。很明显，客户将购买产品，这种能力可以通过接口实现来生成

Interface IPurchase
      Purchase(Product);

，因此您的任何域对象都可以根据需要实现它。通过这种方式，您可以将功能引入您的域对象 - 这正是它应该在的地方。

于 2009-03-04T09:12:49.190 回答
0

您没有提到的一种方法是使用 AOP 来处理您的数据访问。我最近使用这种方法的一个例子（尽管为了发布目的而大大简化）是我有一个Account域实体，它有一个debit方法，封装了从帐户中成功借记所需的业务逻辑。

注意所有代码都是带有 AspectJ AOP 表示法的 Java...

public boolean debit(int amount) {
    if (balance - amount >= 0) {
        balance = balance - amount;
        return true;
    }
    return false;
}

将适当的存储库注入到我的方面，然后我使用切入点来拦截对此方法的调用......

pointcut debit(Account account,int amount) :
    execution(boolean Account.debit(int)) &&
    args(amount) &&
    target(account);

...并应用了一些建议：

after(Account account, int amount) returning (boolean result)  : debit(account,amount) {
    if (result) getAccountRepository().debit(account, amount);
}

在我看来，这很好地分离了关注点，并允许您的域实体完全专注于应用程序的业务逻辑。

于 2009-12-19T10:19:08.613 回答