贫血域模型与领域服务注入

Question

Martin将贫血域模型描述为领域驱动设计中的反模式.为了在域模型上具有业务逻辑，经常使用域服务。但是Vaughn Vernon认为将域服务注入域模型是有害的(参见“实现领域驱动设计，第387页”)。

在我看来，这些意见是矛盾的，这是真的吗？如何考虑这两点呢？

它真的是丰富的领域模型，领域服务注入与贫血领域模型和正常领域服务？

Answer 1

贫血模型只是一个数据容器。它不包含行为。(在功能范例中，这实际上是一件好事。)贫血模型的相反之处不是注入满域服务的模型。你描述的是两个极端--都很糟糕。

如果你有贫血模型，你不会完全接受OOP提供的东西。如果您开始将服务注入到这些模型中，则可能会注入不属于这些模型的关注点。或者你的模型比你想象的更贫血。为什么你还需要这种服务，而不是它所提供的所需但缺失的东西？(失踪可能意味着贫血。)

避免这两个“告诉”导致更强大的设计。你在服务中有模型需要的东西吗？也许它应该移到模型上去。如果没有，也许你应该重新考虑你的担忧。模型的行为应该在模型内部工作。它应该主要(如果不只是)与成员有关。但是请记住，仍然会有一些东西在模型上或与模型一起工作。例如，模型不应该打开TCP连接或侦听UI事件，即使它们在某种程度上涉及到它们。这是别人的责任，而且这个人永远不属于模特。

Answer 2

这并不矛盾。两位支持者都希望您将实际代码放在域对象本身中。

即。

public class Order
{
    private string status = "not bought";
    public void Buy()
    {
        this.status = "bought";
    }
}

对ADM

public class Order
{
    public string Status = "not bought";
}

public class BuyingService
{
    public Order Buy(Order order)
    {
         Order o = new Order();
         o.status = "bought";
         return o;
    }
}

vs注入服务

public class Order
{
    public Order(IBuyingService bs)
    {
        _bs = bs;
    }
    private IbuyingService _bs;
    private string status = "not bought";
    public void Buy()
    {
        this.status = _bs.Buy();
    }
}

public class BuyingService : IBuyingService
{
    public string Buy()
    {
         return = "bought";
    }
}

坦率地说，尽管每种方法都有优缺点。你所选择的主要是个人喜好的问题。