为什么在“贫血的领域模型”被认为是一种反模式具体例子 [英] Concrete examples on why the 'Anemic Domain Model' is considered an anti-pattern

问题描述

我道歉，如果这是一个重复，但我无法找到关于该主题的任何具体的例子在相关问题。

I apologize if this is a duplicate, but I couldn't find any concrete examples on the topic in related questions.

在'贫血的领域模型阅读 Martin Fowler的文章之后，我离开了流浪，为什么是这样的认为是一个反模式。即使完成大部分企业开发人员认为这是一种反模式，因为据我所知大概90％的J2EE应用程序都设计在一个贫血的方式呢？

After reading Martin Fowler's article on the 'Anemic Domain Model', I'm left wandering as to why is this considered an anti-pattern. Even does the majority of enterprise developers consider it an anti-pattern, since AFAIK probably 90% of the j2ee applications are designed in an 'anemic' way ?

有人可以推荐的话题，甚至更好，给这个反模式是如何影响应用程序设计在一个糟糕的方​​式具体的例子。（比领域驱动设计书等）进一步阅读

Can someone recommend further reading on the topic (other than the 'Domain Driven Design' book), or even better, give a concrete examples on how this anti-pattern is affecting application design in a bad way.

谢谢，

推荐答案

由于以下两类：

class CalculatorBean  
{  
    //getters and setters  
}  

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

如果我理解正确的话，福勒指出，因为你的 CalculatorBean 只是一堆getter / setter方法​​你不从获得任何真正的价值，如果你的端口该对象到另一个系统会做什么。这个问题似乎是你的 CalculatorBeanService 包含的一切，在 CalculatorBean 应该负责。这是不是最好的作为现在 CalculatorBean 代表其所有责任的 CalculatorBeanService

If I understand correctly, Fowler is stating that because your CalculatorBean is just a bunch of getters/setters you don't gain any real value from it and if you port that object to another system it will do nothing. The problem seems that your CalculatorBeanService contains everything that the CalculatorBean should be responsible for. Which is not the best as now the CalculatorBean delegates all of its responsibility to the CalculatorBeanService

这篇关于为什么在“贫血的领域模型”被认为是一种反模式具体例子的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！