“贫血模型”这个概念出现的很早，应该是随着“OOP”的问世，也随即就被人提出的一套模型理论。之后是随着“领域驱动设计”概念的流行，又被世人重视起来，并引起广泛讨论，最多的应该就是“失学”、“贫血”、“充血”、“胀血”四种模型
为什么会提及这四种模型？
现在大部分公司或者项目基本都是常见的三层或多层架构：
Cilent层（WEB层）：重交互，用户输入、界面体验等
Service层：重逻辑、鉴权、事务（数据一致性），边界处理，与Cilent通信，与Data Layer通信
Data Layer层：重数据，负责与数据库交互，数据持久化等
可以说service层会随着业务增长和用户需求增加变得越来越臃肿，简单的例子，我曾经负责过的一个项目的Service层，日活订单量大概在20w左右，基本上整个系统需要和7、8个Cilent对接，和超过50个Data Layer层交互，每个需求对于这个系统都是一种负担，每次对项目前期的修改点收集都是很庞大的工作量，这是一个真实的“失血设计”带来的后果。
失血模型
service->DAO-->domain object，其中domain object只有getter/setter方法，没有任何业务逻辑
贫血模型
代码结构service-->DAO-->domain object，其中service负责事务、逻辑、鉴权、边界处理，其中domain object有部分业务逻辑
优点：代码模型简单、各层依赖明显、底层稳定、易于维护
缺点：service负责过多，过于臃肿
充血模型
代码结构service-->domain object<-->DAO，其中domain object有全部业务逻辑，domain依赖DAO
优点：domain承担了自己的所有逻辑，所以service的逻辑可以减少，更专注与事务、鉴权、消息等其他业务逻辑
缺点：service、domain分工不明确，需要整个团队对代码质量有较高的追求，否则个别开发人员的错误意识会导致整个项目朝着不可控的方向发展，对每个成员的素质要求较高。DAO、domain双向依赖，也需要更好的设计及规范才能保持一个较低的后期维护成本
胀血模型
代码结构domain object<-->DAO，简化service层
缺点：虽然解决了充血模型中的service、domain分工不明确的问题，但是也引入了domain承担过多的业务逻辑的这个问题。可能会因为这种设计有，给client层暴露太多不必要的逻辑，反而引起依赖者的逻辑混乱/业务需求不清晰等一系列的问题，对开发人员自身的素质要求也较高，所以不太推荐这种模型。
那么，我实际上遇到了什么样的问题呢？
上文简述了我曾经负责项目的一个概况，三层架构模式“前端-业务-服务”，服务的设计基本遵照单一职责原则和开放封闭原则，在业务不断增加的同时形成了一种习惯：
1、服务的接口数量维持很少的量
2、接口通用性极高
3、服务的接口处于一种“失血模型”的设计，甚至可以看成一个CURD的DAO再封装
以项目中的订单举例，需要订单基本信息、订单额外信息、订单物流信息、订单指派信息、订单交易信息、订单商品信息、异常订单信息等等，暴露出来的缺点最致命的有两个：
1、服务设计太“薄”，比起OOP来说，更像是过程式的增删改查
2、业务太臃肿，在维持业务边界处理、鉴权、入参以及业务逻辑之余，还需要了解服务每一张表中的每一个枚举/字段的具体含义，当面对50多个库和成百上千张表的时候，低效的学习和维护成本急剧增加
如果常此以往继续发展下去，势必会变成业务端变得厚重，而服务层只会更专注于数据库，这样下去会导致的问题是什么呢？
理想模型
1、服务端的接口文档变差，甚至只会写有哪几张表，自己去看，备注看表结构备注，这一点对现有的团队影响较小，但是每个团队的发展都需要新鲜的血液，这样会劝退很多新加入的童鞋
2、服务越来越脱离“产品”需求，长期只专注于数据库会与具体的需求脱节，这样的话也不会关注操作记录这一类的“重要”数据
3、业务看起来很“美好”，业务变大（意味着“权利”更大），但是每个开发者毕竟也是个人不是一台machine，随着业务逻辑变重，总有一天会有考虑不周的地方，就会产生意想不到的bug，代码/业务逻辑臃肿对水平拓展也会是很严重的负担，最后导致牵一发而动全身的窘境。
我的建议
说了这么多，其中窘境大家也都明白了，关于这几点问题的建议是：
1、服务层脱离“失血模型”的设计，选用“贫血模型”来代替，换句话说就是高内聚低耦合，实现服务与需求不脱节
2、服务层更专注的领域是：业务接口设计、数据库设计、数据完整性、以及接口性能、日志监控等等
3、业务层更专注的领域是：鉴权、熔断、业务降级、一致性（强一致性、最终一致性）、安全、业务链路监控以及业务请求服务的顺序（顺序、异步）
4、业务层有可能因此更趋近与一个业务复杂的Facade
网友评论