书中对使用外部配置参数化应用程序的描述是这样的：
如果代码依赖某些值，而这些值在应用程序发布后还有可能改变，那么就把这些值放在程序外部。
使用在外部配置依赖的参数可以使系统更加灵活，在面多不同的环境和用户时，不需要重新编译部署就可以改变一些行为来满足需求。我们系统中也在经常在外部配置依赖参数。
读完这段我在想以下几个问题：
系统中有哪些实现是在使用外部配置参数化应用程序的？
使用外部配置参数化应用程序会带来哪些不好的影响吗？
系统中使用外部配置的地方还有什么可以改进的吗？
系统中还有什么可以使用外部配置参数化的地方吗？
系统中有哪些实现是在使用外部配置参数化应用程序的？
mongDB 配置：我主要用mongDB来存放一些公司的接口配置信息，控制接口的开关。也有同事会用它来实现一些逻辑的开关，上线后可以通过改变mongDB 的值来决定代码运行时具体走那一段逻辑。
LTS 本身的定位是定时触发任务，但是也会带一些参数化的内容。因此可以放一些外部参数。 比如大师的指定供应商和客户门点算费的定时任务，其中供应商和客户门点是可能会发生改变的，就把这些参数存放在了Lts脚本中。
Nginx 中也有一些参数化的配置。比如我们的某些接口在给某客户独立部署OpenApi时，就把一些参数存在了Nginx中。
EAI: EAI的定位是把接口消息递出去和拿回来的“手”。在EAI 中经常会做一些接口消息的转化和与对方交互消息的配置。
其中对接口消息的转化，即xslt， 我不认为是外部系统的参数化配置，我将它认为是应用程序的一部分。虽然它其中确实会有一些参数，比如下面这个例子：
image.png
在转化逻辑中，需要把我们系统的一些值映射成对方系统的值。看起来这是一个代码映射的配置，但是我认为转化逻辑是运行逻辑的一部分，它更像是一段java代码中的静态变量。
而转化逻辑之外的参数我认为是配置参数，如许可证密钥：image.png
使用外部配置参数化应用程序会带来哪些不好的影响吗？
这个我暂时想不到，我觉得他确实可以让系统更加灵活。
系统中使用外部配置的地方还有什么可以改进的吗？
作者提到的“配置数据可以通过专有UI维护”这一点我觉得我们目前可以改进，比如mongDB 的维护，可以考虑有专有UI来维护，不是每次都直接打patch。
系统中还有什么可以使用外部配置参数化的地方吗？
这个问题我没想到合适的答案，我觉得目前系统还是用外部参数的地方都已经应用了。转过去思考了“使用的的度”的问题。我认为不是能用的地方都用就是好的，太灵活反而容易把自己搞死。比如作者提到的日志位置我觉得就没啥必要。
总的来说，在外部配置参数可以使系统更加灵活，使用起来更像是系统有一段可以热部署的逻辑，把依赖的参数包装在一个瘦API背后，在不必重新编译部署的情况下，就可以直接改变系统行为。
