业务架构 序列3 真的分层 vs. 伪分层架构？
有兴趣朋友也可以进一步关注公众号“架构之道与术”， 获取原文。 或扫描如下二维码： 
说到分层架构，相信没有人不知道，一个被说烂的词。无论业务架构，还是技术架构；无论做C端业务，B端业务；无论做服务器，还是客户端，还是别的什么地方，所有人都会用这个。
但就是这样一个熟悉的不能再熟悉的架构方法，却往往被滥用。
下面这个图，展示了一个最常见的一个互联网系统的分层架构：
但是它只是停留在PPT上面，实际的代码、系统是否是按这个分层架构严格执行的呢？ 如果你把所有系统梳理一遍，把系统之间的依赖关系图画出来，往往就不是这样一个分层结构，可能是一个网状结构了。
以上图为例，下面列举一下伪分层架构的可能具有的一些特征（不绝对，但大多时候会反映出问题）：
（1）底层调用上层
比如某个基础服务，调用上层的业务服务。那如果出现了底层调用上层，怎么解决呢？
办法1：你要去思考，这个业务逻辑是否放错了地方？或者这个业务逻辑是否需要1分为2， 1部分放在业务服务，1部分放在基础服务。也就避免了底层调用上层。
办法2：OOD中的典型办法，DIP（依赖反转）。底层定义接口，上层去实现，而不是底层直接调用上层。关于依赖反转的详细内容，此处不再详述，可以百度之。
（2）同层之间，服务之间各种双向调用
比如业务服务1，业务服务2，业务服务3之间都是双向调用。
那你就要思考，服务1,2, 3之间的职责分配是不是有问题，出现了服务之间的紧耦合？
是不是应该有一个公共的服务，让这个公共服务和业务服务1，业务服务2，业务服务3去交互，而1,2,3之间相互独立？
（3）地基不稳：层之间没有隔离，参数层层透传，一直穿透到最底层。导致底层系统经常变动。
举个例子，APP一直发版本，为了做兼容，服务器端有类似下面的代码：
if(version = 1.0)
xxx
else if (version = 1.1)
xxx
else if (version = 2.0)
xxx
然后你发现这样的代码，聚合层有，业务服务层有，基础服务里面也有。这就是典型的“透传”，没有隔离，也就是没有抽象。
虽然是严格分了层，层层调用，但“底层服务“已经不是底层服务，而成了1个大杂烩。
（4）聚合层特别多，为了满足客户端需求，各种拼装
遇到这种情况，往往意味着业务服务层太薄，纯粹是从技术角度去拆的业务。而不是从业务角度，让服务成为1个完整的闭环，或者说1个领域。
总结
上面列举了一个不好的分层架构的种种特征，对应的，也就是一个良好的分层架构应该具有的特征：
（1）系统实际应该和PPT保持一致。PPT上画的分层，实际系统依赖图应该也是如此。
（2）越底层的系统越单一、越简单、越稳定；越上层的系统花样越多、越容易变化。这需要层与层之间有很好的隔离、抽象。
相关链接：
《业务架构 序列2 业务架构与技术架构都怎么区分？》
《让我们聊聊业务架构 – 序列1 到底什么是“业务架构”？》