上一期我们学习了，一个应用架构的四层及职责。但是，随着业务需求的增多，时间的推移，系统架构慢慢的就变乱了。
本文视频语音版本：
我们这期来分析是什么原因导致的。你说是因为“熵增”，这是肯定的。但熵增只是描述了一个概念。
它的表现是什么，根本原因是什么，我们要具象化的来分析。所以，在这之前呢，先让我们先看看变乱后的现象。
出现了两类现象。
图自https://mp.weixin.qq.com/s/jJzzJIGozOpt7KaXwBS3Ww
一类是业务层（biz）变的臃肿，能力层（domain）变的单薄。另一类是出现了网状调用。而且这两类现象也很有可能是混合在一起出现。
1、biz层越来越”胖“。胖了之后，还长成了两小层。上小层是面向单一业务场景的“业务biz层”，下小层成了通用场景可复用的“通用biz层”。
2、service层越来越”瘦“。当service层变薄了以后，也就只能沦为service了，而这样的service层跟dao层实际没什么区别，更不能再称之为domain层。
3、但是也不是所有的service层都变瘦、变薄了。可能有的萎缩，有的膨胀。人员与设计的差异，导致颗粒度不一。
很显然，这违背了“后domain薄biz”的原则。
4、出现了网状调用。原本bizA -> serviceA 的实现链路下，随着新增业务逻辑，又新起了一个serviceB，链路演变成了bizA -> serviceA -> serviceB。“这样的趋势持续发展下去，会发现bizA下的service调用链路越发的复杂，呈现为一颗深度调用树，而biz层失去了业务编排的作用退化为一个业务场景入口的标志符”。有可能后面继续C-D-E-F，越挖越深，不见尽头。
原因：
1、service本身设计的不能扩展，当多种不同类型的业务冲击过来的时候，比如健康、本地生活、门店等多态业务。为了适配这些业务，就需要个性逻辑和共性逻辑的合理安排，做到“和谐共处”。很不幸，因为service本身不能扩展，原本应该在service层的逻辑就上浮到了biz层。
2、可能团队组织大了以后，人员的差异也扩大了。在人员的差异下，service实例的颗粒度设计和实现出来的就不一样了。起初service本身的划分和定位，都比较随意，不跟着领域设计划分，跟着个人的第一感觉划分。
这也是从domain变回service的原因。因为service变薄了，不再能够承载主要的业务逻辑了。
最后一点原因，我个人认为占的比重也是最大的，甚至是主要原因。
3、业务压力下，上线时间卡死。开始倒排需求，于是团队在需求完整度上，架构设计方案上，进行了妥协，去追赶deadline死线。毕竟时间、质量、范围三得很难。于是埋下了长期技术债务的坑。
参考学习资料：https://mp.weixin.qq.com/s/jJzzJIGozOpt7KaXwBS3Ww
