开局三连图。
这是刚开始时的程序结构，虽清晰已经有混乱的前兆。
业务增加，人员增加后就会沉珂日重。
几年后，最后的模样会让使用者和维护者都很无奈。
人们喜欢把Java程序的层次结构比作建筑，实际却最像电力系统，电线的一头接着电源（数据库等存储），另一头接着显示屏（各种view），电线里流动的电流就是各种数据。
每一条私搭乱建的电线都有存在的理由，每一个搭建电线的程序员都有式样需求作为凭据，久而久之就成了混乱不堪的模样。
尽管有程序层次限制，不允许跨层调用，但即使是理想状态的水平扩展，也只是延缓了混乱的速度。
Spring真的帮我们解决这个问题了吗？还是程序就应该是这个样？
为每个从视图到存储源的通道搭建一条管线，Java程序就该这么写吗？
那些成为管道的控制层，业务层，数据存储层代码，那些成为流体的Bean，难道就是程序该有的模样？
当你看到密密麻麻的带着多种参数有着长长名称的管道函数，当你看到一堆只为拼出合理进入管道缩进的if，当你看到不管数据量多少也不管需要多少数据就一股脑拿出来放在Java端过滤归纳的代码，你肯定不会觉得这些都是合理的。
但是，层出不穷的框架包括如日中天的Spring，对此似乎不加理睬，任凭代码在时间流逝和多人参与中腐化，最终烂掉。
管理层常常在假忙，程序员被瞎指挥得一头雾水，这样更加速了项目的腐化。
--2020-04-29--