为什么业务中很少用到设计模式

    老铁们在写代码的的时候，估计多少都沾染一点设计模式这个概念，但很多猿人在实际的开发中发现设计模式用的很少，几乎就是零,这是为何呢?
    设计模式的目的是提供可扩展性和可维护性。但是我们开发的项目本身，大部分都是固定写死的，逻辑单一，我们开发的模块也并不在其他位置或者其他项目中复用，目的很明确就是做当前的业务，支付模块就管支付的业务，推送模块就管消息推送的业务。所以，平时开发中用到设计模式的地方很少。但是框架就不同了，框架必须适应不同的项目，具备高弹性和高扩展性。他们要能适应各种不同的环境，所以，设计模式在框架设计中处处可见。

世界上成千上万的项目都在使用Spring,Shiro,Mybatis，SpringBoot等,那么，他们就必须能满足各种不同的需求，使用不同的配置，插件，定制化，他们不仅要适应你，还要适应他，各种策略模式，代理模式，责任链模式，状态模式，众口难调在这里是不存在的！。比如shiro中的一个token,可能有的项目要使用简单文本密码，可能有些项目已要使用数字证书，这里就必须使用策略模式spring中的事务处理，因为他是框架，他根本不知道自己要放在哪段service对象身上，他就使用动态代理模式，动态的进行运行时施加代理。可以这么说，设计模式为扩展而生，对修改说NO,对扩展说YES! 你绝不会为了项目需要去傻傻的修改spring的源码来适应你的项目需求。
    框架就是这样适应成千上万的项目的。我们的业务逻辑代码，平时开发项目的时候，功能是死的，是专为这个场景而生的，不会在另外的场景中出现，所以，这种代码开发，业务的开发，是不需要设计模式的。对于我们平时开发的项目，如果需求有变化，我们一般的做法，是直接修改源代码了，这样的其实带来了一定的修改成本，但是，为了一个项目中可能不明确的未来变化，而精心设计扩展性很高的架构，成本也是显而易见的，所以，这是一个取舍的过程。深层次的说这是企业开发成本与项目实际应用的一个博弈过程。