软件的灵活性来自哪里？

灵活的软件，可以更好的适应用户的需求。什么样的软件才是灵活的？

一旦用户提出灵活性方面的需求，设计者经常想到的一个对策是：增加配置。在不同的业务环节上增加功能配置，哪里需要灵活性，就把配置写到哪里。配置为软件系统提供了无数个可能——这就是灵活性。但是配置经常复杂无比，失去控制。很多配置项目已经失去了业务意义，完全成为一种数学意义上的排列组合。按照一些配置的路线，业务无法形成闭环流程，走进死胡同。

这样的系统，维护配置和维护程序本身一样复杂。配置，就是不需要编译的代码。

实际上，软件最大的灵活性，来自于完整的业务模型。一个完整的业务模型，不需要华丽的技术——设计模式、先进的平台、巧妙的构思——这些都不重要。重要的是，业务模型需要真实的反映真正的世界。

真实的世界上有“顾客”，那么软件世界里就要有“Customer”，真实的世界上有“帐单”，那么软件世界里就要有“Bill”，真实的世界里顾客可以买东西，那么软件世界里的Customer就有“Buy”方法，参数是Order……

把这些基础的业务模型构思出来，就能够发现，具体的业务需求实现起来会十分的方便。就像用积木搭起一栋房子一样，只需要写一些胶水代码，把业务对象拿来组装一下。

业务模型会有变化吗？当然有。但是业务决不会无中生有的变，也不会没有道理的变。业务模型的变化一定是在原有的基础上添一点东西、改一点东西。一个业务模型能很好的控制变化影响的范围。为了减少这样的变化对模型的影响，各种技术就可以登台了——设计模式、重构……

有一个业务模型，即使是很朴实无华的业务模型，也可以为程序带来极大的灵活性。可以在胶水代码里面增加配置，这样的配置比较容易与用户的业务需要紧密结合，真正的起到作用。也可以把业务对象暴露给脚本引擎，用脚本程序实现一些功能需求。