序言

今天在看文章的时候，有一句话："业务对象贫血模型与充血模型之争"。很好奇的去搜索了下这两个模型。发现大多数文章讲的是比较的笼统，可执行性不高。说白话一点，这2个模型各自有优缺点。我们这篇文章普及下代码分层。写出扩展性强的代码来。

如果需要在你的团队中去推行一套规则的时候，千万要记得先自己用起来。如果确实很爽，在去往团队里推。强推容易遭人嫌弃。

代码分层

利弊

合理分层 可维护性、灵活性、伸缩性、可复用

过度分层 对软件设计人员的要求也越高 开发代价也越大、调试起来也会越困难 (google的openx属于过度的分层)

目的

隔离下层的细节，方便上层调用。切换下层对上层是无感知的 为了未来性能扛不住或者数据层改进预留空间

建议(规定)

分层确定后，调用关系严格按照上层调用下层这种 这样只有上下层的依赖，没有左右的依赖，后续整理划分都很好做

A  B  C  三个层,从上到下。
1、A调B调C 
2、A调C
3、A调B
4、A调A
5、B调B
6、C调B
7、C调B调A

4、5是同层调用，不允许 2是跨层调用，不允许 6、7是反向调用，不允许 严格按照上层调下层的方式，保证链路是从头到尾(从上到下)的

参考

Controller(1) 对用户角色的判断放在controller中 假设放到service层。如果某个controller不涉及角色的判断，是需要直接调service的。这个时候破坏的service中代码的可重用性

拼装service层实现业务 不可以直接引用model层以及ORM层工作 对外来的参数校验，对数据的拼装组合 对外业务只有controller层

---

Service(2) 外部请求不能直接调用，除非使用controller封一层我们业务的API层 对任何输入参数都做校验 是我们能够对外提供的所有服务 另外通用排行服务，模糊查找服务，队列服务都在这层进行封装 Service层不可以相互引用调用

---

Model(3) 对数据类型及必填非必填数据做检测，维护数据的完整性 如果错误抛exception，方便暴露问题(不要像傻子一样一步步往上return异常)

错误处理

Service层（含）以下层级任何异常直接抛Exception（业务错误，redis错误，调用依赖接口错误），方便debug方便调试，排查问题