领域模型？充血模型？是头脑充血后的模型吧

领域建模试图用纯oo的理念来处理企业应用中的数据存取,并细分出失血、贫血、充血与胀血4种模型，失血与贫血被鄙视，充血被推崇。

我向来不喜欢盲目的跟风与崇拜，软件从业多年，亲眼见过多少时髦的词汇和概念从被炒作，被追捧，到被冷落，被替代的过程。所以对被追捧的，被崇拜的，总会冷冷的问一下：真的吗？是这样的吗？

面向对象的提出是为了改善软件开发模式，是为了解决问题的，而不是用来增加新难题。面向对象是手段，不是目的。不要为了面向对象而面向对象。

就说这个领域建模，真的是从实际项目中总结出来，解决旧难题，不添新麻烦的吗？套用一个词汇，是“最佳实践”吗？

尽管各种ORM技术层出不穷，但是到真正的物理存储总得落实到一行行的脚本。这个让我产生了一个问题，现实的世界真的是适合用领域建模倡导者所描述的那样来建模的吗？

领域建模里，实体对应于表中的记录，但是它可以负责自身的持久化。可是我们看看现实的情况，真的用oo的观点来看，这是对的吗？

实际情况是，如果以oo的视角，几乎大部分的实体是不可负责自身的持久化的。结合现实的情况，真的要建模的话，可以抽象出真正有权处置这些实体持久化的类。这些类绝对不是简单对应于数据库中的一张表，而是以下可能的几种：

1. 某个动作或命令，即action/command
2. 规则
3. 由若干实体和规则组成的复合的类型

（以上并不全面，仅是我写的时候想到的几种）

领域建模认为简单的把实体的持续化封装起来，便可以抛开DAO层，便可使实体变得更“面向对象”。我觉得是对真正的“面向对象”的误读。面向对象=/=实体，Action、Command、Rules都可抽象为对象，真正的现实的世界中，是这些对象在支配实体的存续变更。而实体只是被支配。

若你认同我上面述说的观点，那么，我们真正需要建模的是Action、Command、Rules，以及将它们与实体结合起来组成的复合模型，这才是对客观世界的真实映射。DAO不该被抛弃，而是作为一个负责实际物理存取的工具层。

如果你的项目正在使用所谓的“失血模型”，而且实际用下来感觉很好，那又何必因为被鄙视而被迫转向“充血模型”呢？

如果一种开发模式普通人用不好，只有少数的“深刻领悟OO精髓”的“大师”才能用的好的话，那么这样的开发模式又有什么实际意义呢？我觉得这些“大师”应该称之为“大仙”......

转载于:https://www.cnblogs.com/yyfy/archive/2010/08/09/1795385.html