本文来自己张健飞的blog。
复杂性来自哪里
可扩展性差
对于只有一个业务的简单场景，并不需要扩展，问题也不突出，这也是为什么这个点经常被忽略的原因，因为我们大部分的系统都是从单一业务开始的。但是随着支持的业务越来越多，代码里面开始出现大量的if-else逻辑，这个时候代码开始有坏味道，没闻到的同学就这么继续往上堆，闻到的同学会重构一下，但因为系统没有统一的可扩展架构，重构的技法也各不相同，这种代码的不一致性也是一种理解上的复杂度。久而久之，系统就变得复杂难维护。像我们CRM应用，有N个业务方，每个业务方又有N个租户，如果都要用if-else判断业务差异，那简直就是惨绝人寰。其实这种扩展点（Extension Point），或者叫插件（Plug-in）的设计在架构设计中是非常普遍的。比较成功的案例有eclipse的plug-in机制，集团的TMF2.0架构。还有一个扩展性需求就是字段扩展，这一点对SaaS应用尤为重要，因为有很多客户定制化需求，但是我们很多系统也没有统一的字段扩展方案。
If-else， 字段扩展
对于字段扩展，简单一点的解决方案就是预留扩展字段，复杂一点的就是使用元数据引擎。使用元数据的好处是不仅能支持字段扩展，还提供了丰富的字段描述，等于是为以后的SaaS化配置提供了可能性，所以我们选择了使用元数据引擎。
面向过程
不管你承认与否，很多时候，我们都是操着面向对象的语言干着面向过程的勾当。面向对象不仅是一个语言，更是一种思维方式。在我们追逐云计算、深度学习、区块链这些技术热点的时候，静下心来问问自己我们是不是真的掌握了OOD；在我们强调工程师要具备业务Sense，产品Sense，数据Sense，算法Sense，XXSense的时候，是不是忽略了对工程能力的要求。据我观察大部分工程师（包括我自己）的OO能力还远没有达到精通的程度，这种OO思想的缺乏主要体现在两个方面，一个是很多同学不了解SOLID原则，不懂设计模式，不会画UML图，或者只是知道，但从来不会运用到实践中；另一个是不会进行领域建模，关于领域建模争论已经很多了，我的观点是DDD很好，但不是银弹，用和不用取决于场景。但不管怎样，请你抛开偏见，好好的研读一下Eric Evans的《领域驱动设计》，如果有认知升级的感悟，恭喜你，你进阶了。我个人认为DDD最大的好处是将业务语义显现化，把原先晦涩难懂的业务算法逻辑，通过领域对象（Domain Object），统一语言（Ubiquitous Language）将领域概念清晰的显性化表达出来。相信我，这种表达带来的代码可读性的提升，会让接手你代码的人对你心怀感恩的。
看一下公司项目的Java代码，基本上都是面向过程，垒砖头的代码。
分层不合理
俗话说的好，All problems in computer science can be solved by another level of indirection（计算机科学领域的任何问题都可以通过增加一个间接的中间层来解决），怎样？ 是不是感受到间接层的强大了。分层最大的好处就是分离关注点，让每一层只解决该层关注的问题，从而将复杂的问题简化，起到分而治之的作用。我们平时看到的MVC，pipeline，以及各种valve的模式，都是这个道理。好吧，那是不是层次越多越好，越灵活呢。当然不是，就像我开篇说的，过多的层次不仅不能带来好处，反而会增加系统的复杂性和降低系统性能。就拿ISO的网络七层协议来说，你这个七层分的很清楚，很好，但也很繁琐，四层就够了嘛。再比如我前面提到的过度设计的例子，如果没记错的话应该是Apple的Directory Service应用，整个系统有7层之多，把什么validator，assembler都当成一个层次来对待，能不复杂么。所以分层太多和没有分层都会导致系统复杂度的上升，因此我们的原则是不可以没有分层，但是只分有必要的层。
注
随心所欲
随心所欲是因为缺少规范和约束。这个规范非常非常非常的重要（重要事情说三遍），但也是最容易被无视的点，其结果就是架构的consistency被严重破坏，代码的可维护性将急剧下降，国将不国，架构将形同虚设。有同学会说不就是个naming的问题么，不就是个分包的问题么，不就是2个module还是3个module的问题么，只要功能能跑起来，这些问题都是小问题。是的，对于这些同学，我再丢给你一句名言“Just because you can, doesn’t mean you should”。就拿package来说，它不仅仅是一个放一堆类的地方，更是一种表达机制，当你将一些类放到Package中时，相当于告诉下一位看到你设计的开发人员要把这些类放在一起考虑。理想很丰满，现实很骨感，规范的执行是个大问题，最好能在架构层面进行约束，例如在我们架构中，扩展点必须以ExtPt结尾，扩展实现必须以Ext结尾，你不这么写就会给你抛异常。但是架构的约束毕竟有限，更多的还是要靠Code Review。我们在评估代码改动点时，应该可以像Hash查找一样，直接定位到对应的module，对应的package里面对应的class。而不是到“一锅粥”里去慢慢抠。
定义了规范，开发觉得麻烦，不按约定写代码
复杂性应对之道
扩展点设计
身份识别
SOFA架构
————————————————
版权声明：本文为CSDN博主「张建飞（Frank）」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/significantfrank/article/details/79286947