我的潘多拉

从一个故事说起。
从前，有个Java程序员非常喜欢写程序，喜欢研究源码，读英文文档。但是它在一家小公司里工作，公司的技术栈很陈旧。


单个系统代码中含有很多的xml配置，配置各种中间件的入口适配器，而不同的业务系统中都是类似的配置。
启动单个系统很慢。
启动依赖web组件，无法快速部署。
公共组件的依赖复杂，容易依赖冲突，版本陈旧。
在springcloud流行的时代，无法快速集成新的优秀组件。


而且，团队统一使用类似的项目模板，maven多模块，更换的阻力大。
使用统一项目模板可以更好的规范团队的代码结构，遵守公共的公共组件规约，减少了不同的工程师维护代码的成本。

现实很残酷，我爱springboot。


springboot不是新的东西，官网写的目标很强大：build everything ;


可以很好的对症下药，用了之后应该会神清气爽。


springboot提倡零xml,使用java config的模式取代配置代码，通过代码的方式，就有可能消除重复的配置。
springboot的启动速度很快，看了部分源码，有部分异步启动装配组件。
springboot为快速部署而生，内置了web容器无需配置tomcat.
springboot可以使用starter的方式使用公共组件，而且很好的解决了依赖冲突。

springboot积累了大量的最佳实践，为springcloud和各种大的云厂商提供很好的很好的支持。
而springcloud提供了成熟配套的微服务组件,技术更先进，在行业的通用性更强。


那么如何在热爱新技术跟现实的成就的工作中找到一条两全其美的高速公路呢？

如何打开上图中的潘多拉魔盒，连接现实与梦想。

简单直接：
直接把项目骨架改成基于springboot结构的就可以了；
团队习惯多模块，那就改造成多模块的，发布模块改为springboot就好了；
团队封装了很多公共组件，接着用，加个适配器改造成springbootstarter核心代码不变，使用xml接着配置也行，咱兼容并包。


剩下的事情就交给springboot,各种最佳实践，各种好用的组件，拿来就用，955不是梦，多点时间健身，多点时间陪家人。


扩大自己的技术影响力，让更多的小伙伴使用，出任CTO, 改善生活也不是梦。

改造springboot

阿里巴巴的java编程规范大行其道，三层模型流行已久。







分层对应maven的模块，简单画了一下层跟模块的对应关系图。







原来的骨架结构如下图。

rest模块的包约定如下：
按照springboot的最佳实践，所有需要spring自动扫描的类放在xxxApplication类的同级或者下级目录中；

dal的包约定：

配置好mybatis的generator，可以方便生成持久层代码；

代码我也贴出来！

Archetype封装

achetype的流程：

开始流程前，先查阅一下xml的规约如下：

基本结构如下图，英文还比较好理解。

节点里面的元素，看链接，不难。

4 配置模板资源

这里说明一下变量。

_ rootArtifactId 路径占位符_
 \({rootArtifactId}  文件占位符
\){package}  包名占位符

5 安装到本地

mvn clean install

6 本地使用

整理到团队，推广一下这个骨架，然后不断整理已有的中间件到这个骨架中迭代。
早日打开我的潘多拉。




骨架代码点我获取！

原创不易，转载请注明出处。