关于为什么'贫血领域模型'被认为是反模式的具体例子

Question

如果这是重复的话我很抱歉，但我在相关问题中找不到关于该主题的具体例子。

在阅读Martin Fowler's article on the 'Anemic Domain Model'之后，我一直在徘徊，为什么这被认为是一种反模式。大多数企业开发人员甚至认为它是一种反模式，因为AFAIK可能有90％的j2ee应用程序是以“贫血”的方式设计的？

有人建议进一步阅读这个主题（除了“领域驱动设计”一书），或者甚至更好，给出一个具体的例子，说明这种反模式如何以一种糟糕的方式影响应用程序设计。

谢谢，

Answer 1

要获得完整的答案，请查看我的博客，其中还包含源代码示例[博客]：https://www.link-intersystems.com/blog/2011/10/01/anemic-vs-rich-domain-models/

如果从面向对象的角度来看贫血领域模型，它绝对是一种反模式，因为它是纯粹的程序编程。 它被称为反模式的原因是主要的面向对象原则不属于贫血领域模型：

  

面向对象意味着：对象管理其状态并保证它在任何时候都处于合法状态。 （数据隐藏，封装）

因此，对象封装数据并管理数据的访问和解释。 与此相反，贫血模型并不保证它在任何时候都处于合法状态。

订单商品订单的示例将有助于显示差异。 让我们来看看订单的贫血模型。

贫血模型

 public class Order {
    private BigDecimal total = BigDecimal.ZERO;
    private List<OrderItem> items = new ArrayList<OrderItem>();

    public BigDecimal getTotal() {
        return total;
    }

    public void setTotal(BigDecimal total) {
        this.total = total;
    }

    public List<OrderItem> getItems() {
        return items;
    }

    public void setItems(List<OrderItem> items) {
        this.items = items;
    }
}

public class OrderItem {

    private BigDecimal price = BigDecimal.ZERO;
    private int quantity;
    private String name;

    public BigDecimal getPrice() {
        return price;
    }

    public void setPrice(BigDecimal price) {
        this.price = price;
    }

    public int getQuantity() {
        return quantity;
    }

    public void setQuantity(int quantity) {
        this.quantity = quantity;
    }
}

那么逻辑位于何处解释订单和订单项以计算订单总额？ 此逻辑通常放在名为* Helper，* Util，* Manager或简单* Service的类中。 贫血模型中的订购服务如下所示：

public class OrderService {
    public void calculateTotal(Order order) {
        if (order == null) {
             throw new IllegalArgumentException("order must not be null");
        }

        BigDecimal total = BigDecimal.ZERO;
        List<OrderItem> items = order.getItems();

        for (OrderItem orderItem : items) {
            int quantity = orderItem.getQuantity();
            BigDecimal price = orderItem.getPrice();
            BigDecimal itemTotal = price.multiply(new BigDecimal(quantity));
            total = total.add(itemTotal);
        }
        order.setTotal(total);
    }
}

在贫血模型中，您调用一种方法并将其传递给贫血模型，以使贫血模型处于合法状态。因此，贫血模型的状态管理被放置在贫血模型之外，这一事实使得它从面向对象的角度来看是一种反模式。

有时你会看到一个稍微不同的服务实现，它不会修改贫血模型。而是返回它计算的值。 E.g。

public BigDecimal calculateTotal(Order order); 

在这种情况下，Order没有属性total。如果您现在使Order不可变，那么您正在进行函数式编程。但这是我在这里找不到的另一个话题。

上述贫血顺序模型的问题是：

• 如果有人向Order添加OrderItem，Order.getTotal()值不正确，只要OrderService没有重新计算。在现实世界的应用程序中，找出添加订单商品的人以及未调用OrderService的原因可能很麻烦。正如您可能已经认识到的那样，订单也会破坏订单商品列表的封装。有人可以致电order.getItems().add(orderItem)添加订单商品。这可能很难找到真正添加项目的代码（order.getItems()引用可以通过整个应用程序传递）。
• OrderService的{​​{1}}方法负责计算所有Order对象的总和。因此它必须是无国籍的。但无状态也意味着它无法缓存总值，只有在Order对象发生更改时才重新计算它。因此，如果calculateTotal方法需要很长时间，那么您也会遇到性能问题。然而，您会遇到性能问题，因为客户可能不知道订单是否处于合法状态，因此即使在不需要时也可以预防性地调用calculateTotal。

您有时也会看到服务不会更新贫血模型，而只是返回结果。 E.g。

calculateTotal(..)

在这种情况下，服务会在某个时间解释贫血模型的状态，并且不会使用结果更新贫血模型。这种方法的唯一好处是贫血模型不能包含无效的public class OrderService { public BigDecimal calculateTotal(Order order) { if (order == null) { throw new IllegalArgumentException("order must not be null"); } BigDecimal total = BigDecimal.ZERO; List<OrderItem> items = order.getItems(); for (OrderItem orderItem : items) { int quantity = orderItem.getQuantity(); BigDecimal price = orderItem.getPrice(); BigDecimal itemTotal = price.multiply(new BigDecimal(quantity)); total = total.add(itemTotal); } return total; } } 状态，因为它不具有total属性。但这也意味着每次需要时都必须计算total。通过删除total属性，您可以引导开发人员使用该服务，而不是依赖于total的属性状态。但这并不能保证开发人员以某种方式缓存total值，因此他们也可能使用过时的值。只要从另一个属性派生属性，就可以实现这种实现服务的方式。或者换句话说......当您解释基本数据时。例如。 total。

现在看一下富域模型，看看它们之间的区别。

富域方法

int getAge(Date birthday)

富域模型尊重面向对象的原则，并保证它在任何时候都处于合法状态。

参考

• 博客：https://www.link-intersystems.com/blog/2011/10/01/anemic-vs-rich-domain-models/
• 来源：https://github.com/link-intersystems/blog/tree/master/anemic-vs-rich-domain-model

Answer 2

Martin Fowler为这个行业带来了许多话语和不太了解。

今天的大多数应用程序（web / db）确实需要许多公开其属性的对象。

任何对这种做法不屑一顾的权威（自称）都应该以身作则，并向我们展示一个成功的现实世界的应用程序，其中充满了他奇妙原则的体现。

否则闭嘴。令人作呕的是，我们这个行业有如此多的热门话题。这是工程学，而不是戏剧俱乐部。

Answer 3

好。你是对的，几乎所有的java代码都是用这种方式编写的。它是反模式的原因是面向对象设计的主要原则之一是将数据和对其进行操作的函数组合成单个对象。例如，当我编写旧的学校代码时，我们会像这样模仿面向对象的设计：

struct SomeStruct {
    int x;
    float y;
};

void some_op_i(SomeStruct* s, int x) {
    // do something
}
void some_op_f(SomeStruct* s, float y) {
    // something else
}

这就是说该语言不允许我们在结构内部组合函数来操作SomeStruct，因此我们创建了一组自由函数，按惯例将SomeStruct作为第一个参数。

当c ++出现时，struct变成了一个类，它允许你将函数放入struct（class）中。然后结构被隐式地作为this指针传递，因此不是创建结构并将其传递给函数，而是创建类并对其调用方法。代码更清晰，更容易理解。

然后我转移到java世界，每个人都将模型与服务分开，也就是说模型是一个美化的结构，而服务，就像它一样无状态，成为一个运行于模型。对我而言，听起来像是一种c语言成语。这很有趣，因为在c中它完成了因为语言没有提供更好的东西，而在java中它已经完成了，因为程序员不知道更好。

Answer 4

鉴于以下两个类：

class CalculatorBean  
{  
    //getters and setters  
}  

class CalculatorBeanService  
{  
   Number calculate(Number first, Number second);  
    {  
       //do calculation  
    }  
} 

如果我理解正确的话，Fowler声明，因为你的CalculatorBean只是一堆getter / setter，你没有从中获得任何真正的价值，如果你把那个对象移植到另一个系统，它将什么都不做。问题似乎是CalculatorBeanService包含CalculatorBean应负责的所有内容。哪个不是最好的，因为现在CalculatorBean将所有责任委托给CalculatorBeanService

Answer 5

与软件开发领域的大多数事情一样，没有黑色和白色。有些情况下，贫血领域模型非常适合。

但是在很多情况下，开发人员尝试构建域模型，也就是做DDD，而最终导致贫穷的域模式。我认为在这种情况下，贫血领域模型被认为是反模式。

请确保您使用最适合工作的工具，如果它适用于您，请不要更改它。

Answer 6

它违反了“告诉，不要问”原则，该原则规定对象应该告诉客户端他们能做什么或不能做什么，而不是暴露属性并将其留给客户来确定如果对象处于特定状态以进行给定的操作。