框架搭建自我见

搭建框架不仅是技术选型或编写代码，也是制定一套标准。

---

前言

最近和别人聊起技术选型，以及框架搭建，别人经常说，很简单的事情。但我却以为，这其实是一件复杂无比的事。我从没看过有人能把这件事做好，包括我自己在内。我以为搭建框架不仅是技术选型，或编写代码，它也是一套开发规则的制定过程。我打算写几篇文章，从我的工作实践出发，聊聊自己是如何搭建框架的。这可能是一篇很长的文章，我可能会分几篇去写，也可能在此篇的基础上不停地添加新内容

PS:我写博客的目的，一是为练练手，二是为了理清自己的思路，三是希望有些公司的技术面试者可以通过我的博客，了解我的思想。

---

一、搭建框架概述

有很多人以为，从Spring官网上用工具生成一套项目，或者在网上下载一个脚手架工程，修改一下，就完成了底层的框架的搭建了。用spring的原生的项目，以后造成大家各自为证的结果，每个团队成员都会自己的一套东西，这不利于团队间的交流，也不利公司技术的沉淀。 用脚手架工程往往造成业务的混乱，因为每个公司有自己的业务，这些业务往往决定了组织结构。用户体系等，如果生搬硬套，便后患无穷。 我以为搭建框架不仅仅是技术活，其实与你的业务息息相关，我在制定框架时，我可能会考虑这几方面：

1. 团队主要的业务
2. 当前流行技术
3. 当前团队成员的编程习惯
4. 运维部署
5. 后继扩展

制定共享接口与数据类型

我喜欢建一个叫core的模块，这个塻块会存放一些公有数据类型，比如说用户类（User），还有一些抽象的接口，这些接口定义了我以后所有模块将要调用基础模块的方法。（依赖反转）。我会将这个模块推到maven的公有仓库中，供其它服务引用。
这个core模块，必需从实际业务出发来制定，但它又不是具体的业务实现。他只是一个协议，规定了我Rpc调用时基础服务提供方与调用方共同遵守的规则。
我上面用到了基础模块这个词，实际上，我在搭建框架之初，我会将整个系统，归类为三种类型：主业务，基础业务，以及支撑业务。

以我上家公司的TMS系统为例： 主业务：运单整个生命周期的状态变化 基础业务：用户、网点、以及字黄 支撑业务：路由，结算，及时消息。订单 其中基础业务模块会被其它两种业务类型依赖，所以在项目启动之初，我应该把基础业务的数据类型及接口确定下来（不是实现）。

制定统一的接口数据格式

很多设程序设计者，往往要靠一堆文档来约束接口规范，但我更喜欢通过代码进行约束，文档公是仅为辅助，比如我会定义业务异常，设全局异常拦截，对业务异常作固定数据封装。还可以定义一个标准的接收数据格式，利用HandlerMethodArgumentResolver对参数进行变化。

定制化Spring组件

spring是一个很灵活的框架，我们可在很方便在此基础上进行扩展。如上篇所言，我曾自定义一些注解，并在我项目启动时初始化我自定义的一模块。以后我会贴出一些代码，并作一些解释。

如何配置

业务端的程序员，希望只需要点一下IDE上面的一个按钮，或一行简单命令就可以轻松启动项目。运维人员肯定希望程序能轻松部署，并且可方便修改配置。Spring-boot中鼓励我们在不同环境中，使用不同的配置。因此有很程序员会将生产环境的配置写到项目中去，这是很槽的做法。生产环境的一些敏感信息其实不该暴露给程序员。

代码管理

如何约束团队成员