1.业务逻辑同学
业务逻辑同学经常被大家戏称是业务中最不讲逻辑的东西， 这句话道出了他的本质。
这家伙不仅善变，而且特别喜欢和程序员作对，尤其喜欢制造混乱，让程序员惧怕他。
他最早栖息在像ASP 和 JSP这样的页面当中，整天和那些负责界面展示的HTML,CSS们厮混，在这里除了展示逻辑之外，你还能看访问数据库的代码， 他们坚定不移地以制造混乱为己任，齐心协力把页面搞得一团糟。
当程序员想去修改的时候就发现， 这种代码简直就是“意大利面条”， 极难阅读，极难维护。 更不用提什么代码的复用了。
每当程序员抱怨的时候， 业务逻辑说： “怪我咯? 还不是你们自己惹的祸!”
2 ***次搬家
时间久了，大家都受不了， 只好想了新的办法， 分层! 强迫业务逻辑和展示逻辑分家 !
业务逻辑被迫搬了家，再也无法和展示层的HTML,CSS一起喝酒吃肉， 每次想聊个天还必须得通过特定接口， 把数据发给展示层才行。 比如业务逻辑层会发个View Object 给展示层，把自己的孤独和思念捎带过去。 再后来展示层完全从服务器端移到了浏览器端，业务逻辑想打个招呼就得跨越网络的千山万水了。
业务逻辑退而求其次， 和Java bean 打得火热，不过很快就发现和Java bean 实在没什么好聊的，太单纯，没有一点深度，除了getter/setter方法之外，啥都没有。
有人把此时的业务逻辑称为Service , 有人称为Manager ，业务逻辑更喜欢这个名字，因为显得更加威严，更像系统的老大。
无论叫什么，其实做的事情都是一样的： 根据隔壁房间或千里之外的展示层传过来的指示， 从数据库读取数据，形成java bean(有时候连java bean 都不需要) , 进行业务逻辑运算，再给展示层发送结果。
程序员把这种Java bean 形象地称为贫血模型， 因为它一点业务逻辑都没有， 业务逻辑在Service中放着呢。
这种简单的开发方式受到了广大程序员的欢迎，它概念简单，门槛极低，初学者很快就能掌握。
建个数据库表， 创建一个对应的java 类，使用Hibernate, MyBatis把它映射到数据库表和字段上， 接下来就可以在Service 中随心所欲地操作这些Java bean 实现业务逻辑了，完全不用什么“高深的”面向对象的分析和设计 。
一个项目划分成多个模块， 大家都按照这种模式开发， 再加上一些辅助的开发工具，能够自动化从数据库表生成各种类， 实在是直接而酸爽。
一大批使用贫血模型的应用程序如雨后春笋般地出现，慢慢地变成了趋势，好像用Java做面向对象的Web开发就是这个样子。 尤其是后来维护项目的程序员， 更是觉得天经地义。
(码农翻身老刘注： 按照Martin Flower在《企业应用架构模式》中的定义，这种方式叫做事务脚本，其本质是用面向对象的语言写面向过程的程序)
这种模式对于简单的增删改查一点问题都没有，甚至还有优势 !
业务逻辑这家伙经常在诱惑程序员，来啊来啊，再多给我的Service/Manager加点逻辑。
随着系统越来越复杂， 这家伙得逞了， 大量的业务规则被添加到Service 当中，Service越来越臃肿， 开始变成巨无霸的类， 各种状态、判断、if else 交织在一起， 喜欢混乱的业务逻辑同学又激动起来， 又回到了“面条代码”的“美好”时代。
3 第二次搬家
程序员们决定再次让业务逻辑搬家， 搬到一个清静的地方去。
有一天，有个叫做Eric Evans的大神提出了一个新方案： 把Service 层和领域层分开。
(码农翻身老刘注： 在Eric Evans的领域驱动开发中，最下面是基础设施层，而不仅仅是数据访问， 我这里为了和之前的图保持一致，只把数据访问列了出来)
业务逻辑同学很不爽地发现，自己不但和展示层彻底说byebye ，还被拆分到一个个的领域对象当中去了，这些对象不仅仅是具有getter/setter的java bean , 而且拥有相关的业务逻辑、业务状态、业务规则。 现在各个领域对象要想聊天吹牛，也非得调用相应的业务接口才可以。
原来的Service 层也成功减肥，变得非常轻薄，不再包含业务规则和知识，只是为下层的领域对象协调任务，分配工作，指挥着他们完成业务任务，解决问题。
程序员们被美好的前景激励着， 努力地帮着业务逻辑再次搬家。 喜欢混乱的业务逻辑同学这次要绝望了， 以后的系统都这么搞，自己还有什么活路。
可是没想到这一次搬家难度很高， 尤其是从需求中分析合适的领域对象，实在不是一件轻松的事情，习惯了之前那种用数据库表驱动的开发方式，想转到领域模型驱动的开发方式， 让大家很不适应。
于是业务逻辑同学趁势鼓噪，算了吧，这种方法太难了，你有丰富的开发经验吗?、你有优秀的面向对象设计能力吗?你能把业务领域专家拉进来一起讨论设计吗? 不行吧? 还是退回去吧，贫血模型多好，又简单又熟悉。
这厮还真得逞了，鉴于大部分遗留系统都是贫血模型，大家没有勇气更没有时间去重构，只好将就着继续往混乱的Service舔砖加瓦，希望能熬到系统重写的那一天。
业务逻辑再次搬回到熟悉的地方，再次开始幸福的生活。
【本文为51CTO专栏作者“刘欣”的原创稿件，转载请通过作者微信公众号coderising获取授权】
