框架层面的架构与设计的度

这算是一个伪命题，不同的架构人员、不同的行业应用等，会有不同的架构方式，同时架构的使用和受众群体不一样，也会影响架构的设计，尤其是在做通用框架层面。

框架的设计其设计的度，就如操作系统的内核设计，是一个能高效执行一切的单一内核，还是一个只负责调度的微内核，在框架设计中，也是有这个问题，你不可能去面对所有的使用者，使用者总有自己的个性化需求，如果包容太多，势必会造成灵活性和受众领域的影响，如果包容太小，又想是只开放了一个空壳，所有的工作还是在使用者头上了。

这个度的把控，就分外困难了，以一个日志记录系统的架构为例，日志系统都是辅助业务和调度系统而存在的，目的是记录运行中或调试中的异常、操作等信息，如果想做一个通用的日志记录框架，就需要去面对各种应用场合，可能是实时系统也可能是财务系统或业务系统，因为应用场合的不确定性，所以作为通用日志记录框架，就要尽可能的可扩展和灵活，但同时又能框定使用边界，接口统一，这就需要在日志调度的开放性和扩展性上，与调用的约束性上进行均衡。

这个度的把控，还有一方面体现的淋漓尽致，在现代软件部署中，因为软件规模性的增大或通用性的提高或平台性的提高，我们需要各种不同的配置信息，应对不同的使用场合，作为一家项目性质的软件公司，可能希望永远不需要去编译源代码，只需要拿成熟的产品，修改一下配置，就满足用户的需求，但是大量的配置信息引入系统内部，势必造成业务的中断，尤其是对开发者来说，可能一行代码就能实现的功能，却需要想办法统一纳入配置文件中，很多时候，开发人员会存在疑惑，究竟哪部分应该进行统一配置，哪一部分应该直接Coding就可以了，这也需要在设计上做一个度的把控，配置文件的灵活性太高，也未必是一件好事，这会造成实施人员，疲于去记住各种参数信息。必要与没必要之间总是那么难以把控，但是软件工程的思想中有一点是，封装变化的部分，在配置处理时，我们也应该，把配置放在变化上，其他部分，总会能找到各种软件工程模式来统一出来。