domain-driven-design - 处理贫血域模型的技术

Question

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

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) 这样的方法也很有意义，但这会将域逻辑放在实体上。

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

Customer 和 Product 继承自“Entity”类，该类以通用方式提供基本的 CRUD 操作(可能使用 ORM)。

优点:每个数据对象都会自动获取 CRUD 操作，但随后会绑定(bind)到数据库/ORM

缺点:这并没有解决对象上的业务操作问题，并且还将所有域对象绑定(bind)到可能不合适的基础实体

使用帮助类来处理 CRUD 操作和业务逻辑

将 DAO 用于“纯数据库”操作是否有意义，而将业务助手用于更特定于业务的操作是否有意义？

为此使用非静态或静态辅助类更好吗？

优点:域对象不绑定(bind)到任何数据库/业务逻辑(完全贫乏)

缺点:不是很面向对象，在应用程序代码中使用助手不是很自然(看起来像 C 代码)

使用 Double Dispatch 技术，其中实体具有保存到任意存储库的方法

优点:更好的关注点分离

缺点:实体附加了一些额外的逻辑(尽管它是解耦的)

在 C# 3.0 中，您可以使用扩展方法将 CRUD/业务方法附加到域对象而不接触它

这是一种有效的方法吗？什么是优点/缺点？

其他技术？

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

Answer 1

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

逻辑如:
"Customer.PurchaseProduct(Product product, Payment payment)",
“Customer.KillCustomer(人员杀手，武器武器)”
应该存在于“客户”域对象中。

逻辑如:
“客户.IsCustomerAlive()”
“客户.IsCustomerHappy()”
应该去规范。

逻辑如:
“客户。创建()”，
“客户。更新()”
显然应该去存储库。

逻辑如:
“客户.SerializeInXml()”
“客户.GetSerializedCustomerSizeInBytes()”
应该去服务。

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

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

编辑:

有时 - 贫血域模型 shouldn't be avoided .

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