软件系统的复杂性

软件系统，就是使用软件技术来实现业务价值。所以，软件系统本身包含两个方面：

1. 业务
2. 技术

业务才是软件系统的核心价值之所在。试问，如果软件使用了非常先进高超的技术，但是却没有解决业务问题，这样的软件有何意义？

然而，现状是大部分开发人员更看重技术，而忽略了业务。为什么会这样？我想可能的原因是：
其一，技术虽然服务于业务，对开发这来说却是起点，如果没掌握好技术，又如何服务于业务呢？
其二，不同公司业务需求不同，对作为打工者的开发人员来说，技术经验更通用，业务经验不容易迁移。

好像跑题了。

同样的，软件系统的复杂性也分成两个方面：

1. 业务复杂性。这部分的复杂性是业务本身的复杂性，所以是核心复杂性。是由复杂的功能性需求所驱动的。
2. 技术复杂性。这部分是由非功能性需求所驱动的，比如安全性、可用性等。属于外围复杂性。

技术复杂性更通用，所以有普遍的解决方案，如安全框架、代理或负载均衡器等等。正因为这方面的方案更通用且看得见、摸得着，所以，不论开发者经验如何，对技术框架都是或趋之若鹜或津津乐道。

随着互联网的发展，系统面向的用户更广泛。为支撑大体量的用户和大并发量，技术架构快速发展。特别是几乎被奉为圭臬微服务架构，对运维提出了前所未有的挑战。从虚拟机到容器，云原生成了标配。纵观整个软件技术发展路径，应对技术复杂性的方法与工具，有了巨大的发展，技术复杂性得到一定程度上的解决。

再回过头来看软件的核心复杂性。虽然，十多年前《领域驱动设计》就提出通过划分子域与界限上下文（个人不喜欢这个翻译，感觉“限定语境”更简洁达意）来形成统一语言，以同步业务需求、设计与代码，至今业内在实践上并无标准。此处迷雾阵阵，正是考验架构师实力与经验之所在。