印象中有几天没写文章了，最近一直在放飞自我。今天，我想和大家分享一些脚手架和编程的实用原则。所有目标都是“清晰的架构分层”。这样使用统一的依赖管理，是我这些年的实践。一开始，我也是随意管理项目类库和它的版本。大多数情况下，它们可以正常工作，但遇到版本升级和依赖冲突时就很头疼了。于是模仿一些知名开源依赖的管理，定制自己的BOM，像这样：>1.0pomimport这样你的依赖管理会很清晰，当升级第三方依赖或者增减依赖时，只需要升级这个依赖的版本即可。约定大于配置。众所周知，SpringBoot的一个重要特点就是约定大于配置。但是我在一些开源脚手架和一些项目中看到的并不是这种思路的延续，大量代码用于实现一些可有可无的自定义配置。比如我在某项目的SpringSecurity依赖中看到，所有的默认配置都被自定义了，把简单的问题复杂化了，但收效甚微。默认提供的PasswordEncoder不好用吗？能复用就复用，用最少的配置解决问题。MVC的分工应该集中和简化控制器。关于controller，即Controller，它更多的作用应该是一个协调者和委托者，而不是承担具体业务逻辑的执行。controller应该专注于HTTP层面的功能，比如参数绑定处理，序列化和反序列化，具体的业务委托给下游的服务层。还有一点就是界面的命名风格要保持一致，还要有层次感和语义。例如/api/user/{id}、/api/order/{id}、/api/order/user/{id}。服务层我在服务层遇到的问题是散出口的问题。很多同学订单的导出可能因为某些原因分散在其他服务层接口，而不是集中在OrderService中。大多数情况下，我认为集中管理有利于后续的迭代维护，保证各个领域业务的相对独立性。还有一点，同一个Spring容器下的服务层之间相互调用，很可能会造成依赖循环问题。比如UseService调用OrderService查询订单，OrderService可能依赖UserService。最好的方法是避免服务层之间的相互影响。Call，调用持久层的OrderMapper，当然一些功能接口服务除外，比如短信服务，三方接口。对于短信服务和三方接口，建议集成类库等稳定的业务功能，方便管理，可复用。工具类Spring内部的工具类和apache公共包的工具类足以应对大部分情况。如果实在不满意，再考虑写工具类。工具类一定要解决局部问题，不要封装业务功能相关的东西。成工具。
