DDD失血贫血模型

充血模型有什么实际的好处么？ 难道就为了好听 完美（数据和行为统一）？ 过于复杂的需求还是用贫血 ,一般需求用充血 ,这样做正确吗？ 项目中用的更多的哪个模型呢。 比较

项目中的领域模型,我一直只为模型的各个属性提供set/get方法,这样的模型被称为失血模型,这样影响了对象的完整性,是一种不完全的面向对象设计,但在实际中,这样的设计我觉的很直观,而且可以加快开发速度,不知道我这样的开发方式是不是破坏了对象的完整性?有多少开发者在现在的工作中也使用的这样的开发方式呢

如题.使用POJO产生了什么样的好处?怎么觉得从模型里把方法剥夺了，看起来那么奇怪呢?

关于暴露业务模型（Exposed Domain Model Pattern） 这个问题涉及到企业应用社区中许多流行了好多年的热门词：POJO，DTO（VO），FAÇADE。这个问题非常复杂，比贫血模型更易引起争论；其中由方法论层面上的问题，也有技术层面的问题，在这里也无法给出全面的分析，那

关于贫血模型 贫血模型的问题与所谓专家原则以及分层原则直接相关。面向对象系统的主要任务就是安排对象系统的责任划分以形成合理的协同关系；专家原则是说，某个功能、行为应该分配给持有相关信息最完整的对象；显然，专家原则与关于高内聚的思想相一致。分层原则是就系统的大结构而言，企业级应用以业务逻

-->>失血模型 　　MF（Martin Fowler）曾经提出有名的贫血模型或失血模型，让我们好生迷惑和彷徨，他认为实体模型对象中只有弱行为setter和getter方法，没有真正行为，好像缺少血液的人，不和谐了，不少高手又被忽悠了，大谈贫血模型。

对于公司简介，或者公司概况之类的只有一条记录，并且还要求能够修改的栏目，该如何设计和建模。我以前是把他设计成一个领域模型，但是不给他添加和删除的动作，但我老感觉这不够优雅。各位高手是这么做的呢？

这如何理解?DDD我觉得很是能自圆其说的一种设计思想.一直想把的什么失血和贫血,BO,VO,POJO,还有怎么分层跟DDD作一个整合.一些基层框架可以DDD提供服务,比如ibatis,我觉得这些东西如果放在DDD这么一个环境下能很好的解释. 但现在总感觉没突破这一层.

大家能详细谈谈DTO、BO和PO吗？从它们三的本身和应用的环境。

最近自己做了一个东西，也是看书看多了，就想自己实现一下，跟大家说说，给点意见 我作的是一个很小的东西，类似于购物的网站，Domain层使用充血模型，对所有的Entity、ValueObject 进行建模,我的原则是所有关于Persistence操作放到每个

今天在jdon看到一片关于领域模型的文章，心里总结了一下 下面是个人观点！ 贫血模型是对OO的非常经典的诠释！数据交给s/g，业务全部交给业务对象来完成。耦合度很低，逻辑清晰，重构空间大！而且在业务逻辑上

最近看domain model，好像大家都很摈弃失血模型，认为domain object中不能只有getter/setter代码，而应该加入不依赖於持久化的逻辑方法为什么呢？谢谢

今天看了robbin在javaeye上关于domain object的总结:总结一下最近关于domain object以及相关的讨论

BO里的字段总会有各种类型：int、DateTime、string、float、decimal等。最近和个朋友正在架构公司的底层平台，朋友坚持所有的字段都用字符串来表示。小弟我总觉得这样做不妥，和朋友争论了一番。原来正常一个类变了个样： class EmployeeInfo

最近总是在思考Domain Logic Patterns的几种形式，这也让我不得不从先哲们的书中探寻答案。看了下martin 的Patterns of Enterprise Application Architecture，感觉略微明白了点事情。 在Dom

小弟现在做的项目，用的是mvc模式，现在在web这端，用command模式处理接受表单的数据，调用 业务逻辑端delegate的业务处理，现在遇到一个比较模糊的问题：在command端我传送的是javabean到delegate端，进行业务操作，我的做法是先生成所有要操作到的javabean，这样在