浅谈贫血模型和充血模型

浅谈贫血模型和充血模型

想当初怀着满腔热血学了Java编程，依稀记得在大学课堂上，老师的第一堂课就是讲了什么是面向对象，面向对象和面向过程的区别，听完老师的慷慨激昂心里真的是对面向对象充斥着敬意，以至于自己在很长时间都觉得自己以后肯定是面向对象编程。但是我真的是在工作中一直在使用面向对象编程吗，又或者说大部分时间都在用面向对象的思路编程吗？
大家都知道java是一门面向对象语言，但是面向对象语言写出来的程序就一定是面向对象的吗？
并不是！！仔细想想其实我们平时写项目的时候都是SQL-DRIVEN的开发模式，我们平时在接到需求时，总是先考虑接口返回的数据对应到数据库的那几张表，然后就顺理成章的会先去想sql怎么写，之后就是定义Entity，BO，VO，然后就是模板式的往对应的Service，DO，Contoller类中添砖加瓦。业务逻辑都包裹在大的sql中，service层反而做的事情很少，但是很多时候sql都是针对业务的，复用性很差，我们在写另一个功能的时候又要重新写满足当时需求的新sql，这就导致很多长的差不多的，区别很小的sql哪哪都是，很难维护，不要问我怎么知道的，问就是泪！
说了很多废话，言归正传，你还记得什么是面向对象吗？我们来重温一下，面向对象方法，把相关的数据和方法组织为一个整体来看待，从更高的层次来进行系统建模，更贴近事物的自然运行模式。这里很重要的一点就是相关数据和方法这一点，我们的Entity，BO，VO这些POJO都是只有数据没有方法，Service，Controller，DO都是只有方法没有数据，所以我们平时典型的面向过程的编程风格，而这种只包含数据，不包含业务逻辑的类就是贫血模型，相反同时包含数据和业务逻辑的类就是充血模型
要知道这世界上没有所谓的银弹，充血模型就一定好吗？贫血模型就一定差吗？答案肯定是否，试想一下如果我们当前业务很简单，没有复杂的计算模型和算法模型的创建，我们只是简单的CRUD可能，然后我们选择了充血模型，紧接着我们就要进行一系列的领域划分，经过漫长的事件风暴讨论模型需要暴露哪些接口，需要包含哪些逻辑。最后等我们设计完，人家采用贫血模型在就已经完成了一次上线，更甚者都已经完成一次翻新了。所以我觉得各种各的好处，一昧的推崇充血模型的DDD开发模式其实是不可取的，那么什么项目更是适合充血模型的DDD开发模式呢？网上很多人说充血模型适合开发复杂的系统，贫血模型适合开发简单业务系统，但是为什么贫血模型就不能开发复杂系统？其实我觉得很重要的一个区别在于，两种不同的开发模式会直接导致我们后续采用不同的开发流程，贫血模型的开发流程就是SQL-DRIVEN的流程，如果我们在项目中，应用基于充血模型的 DDD 的开发模式，那对应的开发流程就完全不一样了。在这种开发模式下，我们需要事先理清楚所有的业务，定义领域模型所包含的属性和方法。领域模型相当于可复用的业务中间层。新功能需求的开发，都基于之前定义好的这些领域模型来完成。越复杂的系统，对代码的复用性，易维护性就要求越高，所以我们应该花更多时间和精力在前期设计上，而基于充血模型的 DDD 开发模式，正好需要我们前期做大量的业务调研、领域模型设计，所以它更加适合这种复杂系统的开发。其实通过看每一个优秀的框架和语言设计都是既有贫血也有充血模型，取长补短。
以上均是个人看法，欢迎大家指正！