关于web项目架构-随笔

无配置概念

现代架构流行的是无配置，说的是没有一个能够叫做配置的文件或文件夹。

• 所谓配置：如果修改了配置，会导致某些代码改变行为。比如我可以传入真的db，也可以传入mock的db对象，这会改变service的行为，“传入db的代码”看做配置，很显然这类配置是分散的。配置分散在代码的各个角落，这是第一种无配置的写法。第二种是配置分散在代码的各个角落，再由一个解析器搜集这些配置最终生成一个总配置，由于生成的过程是自动的，所以在最终观感上跟第一种一样。偶尔会有全局变量，这是只是简单的代码技巧，比如把重复使用的字符串写成一个全局常量，这这类全局的东西不允许跨层使用，否则是分层分的不对或者滥用全局。这么看来router层显然违反了这个，所以router信息应该放在controller里。当然我们需要反模式，router单独分层是为了方便添加中间件，否则就需要在controller层里增加描述controller的关系的代码，比如把多个controller函数放在同一个类里，这样就可以共同配置一个中间件，“描述controller之间公用一个中间件的代码”看做配置，这虽然符合配置分散的原则，但是最终会发现这样代码量比“配置集中但router层”还要多，另一个要反模式的理由是这样会导致出现无意义的类，controller里这种类找不到其抽象意义。

• 所以最终会出现数据库表的描述层，和路由层，这两个反模式。应用类配置比如业务说晚上五点开始签到，这个需要用另一种策略，“五点”一开始可以写到分散的代码里，如果后来需要修改则放到全局变量但不能跨层，再后来放到外部配置文件，外部配置文件是跨层的但重要的是不需要重新部署，再后来放到数据库由后台管理进行配置由运营人员修改。代码里永远不需要一个跨层的配置文件或文件夹，最多需要一个不跨层的全局常量，或者一个用来不需要重新部署的外部配置，虽然外部配置是跨层的但他不算代码呀。

• 所以类似数据库密码之类的配置直接放到service层，或者外部配置比如环境变量。或者打包工具的打包时配置

这是一套完全自洽的，既有模式又有反模式的架构，还符合约定大于配置的主流思想，是我在折腾微服务的时候总结出来的，这个架构很简单，难在如何说服别人放弃多余的分层和代码中的全局配置。当然架构之所以是这样还有很多底层原理比如副作用管理，单方法接口，无用的依赖注入，配置中心。