二方库
| 名称 | 说明 |
|---|---|
| 一方库 | 指项目内的各个模块，一般不会被项目组外所使用，通常使用的是最新版本 |
| 二方库 | 指公司内部公共库，会被公司的各个项目组所使用，而且每个项目组所依赖的版本不一定一致，需要严格管理版本 |
| 三方库 | 一般代指公司外部的公共库，由公司外的开发团队进行版本维护，版本可控性难以控制，公司引入的时候要进行严格的版本验证 |
在实际项目中一个订单系统通常会是下面的结构
order-server中是订单系统的业务代码，而order-api中会定义一些接口和入参和返回值，order-api会被同项目的其他系统所依赖，也有可能会被其他项目组的系统所依赖，所以一方库和二方库的界限一般比较模糊，下面主要探索api项目的结构规范。
为避免二方库的依赖冲突问题，二方库的发布应该遵循以下原则
- 精简可控原则，移除一切不必要的API和依赖，只包含Service API，必要的领域模型对象，常量、枚举等，如果依赖其他的二方库或者三方库，尽量的使用
provided引入，让使用者选择具体使用的版本号。 - 稳定可追溯原则，每个版本的变化应该被记录，除非用户主动升级版本，否则二方库的行为不应该发生变化。二方库的新增或者升级需保持功能点之外的依赖不应该发生改变，如果需要发生改变，需要给出明确的评估和验证。
除以上两个原则外，还总结了以下需要注意的关键点
-
二方库中可以定义枚举类型，参数可以使用枚举类型，但接口的返回值禁止使用枚举类型或者包含枚举类型的对象。
说明：随着功能的迭代，枚举类型有可能发生变化，参数中使用枚举类型可以限制相关字段的合法性，但是返回值中则不同，如果后续版本中枚举增加，而其他系统依赖的是低版本的库，那么使用者在进行反序列化时会发生异常。
-
二方库的新增或升级，保持除功能点之外的其它 jar 包仲裁结果不变。如果有改变，必须明确评 估和验证。
说明：在升级时，进行
dependency:resolve前后信息比对，如果仲裁结果完全不一致，那么通过dependency:tree命 令，找出差异点，进行排除 jar 包。 -
建议将依赖的放在父项目的
中，所有版本仲裁放在 语句块中。 说明：
只声明版本，并不引入，因此子项目中需要显示的引入，version和scope都读取 中的声明。而 所有声明里的依赖都会自动引入，并默认被所有的子项目继承。 -
二方库中尽量不要有配置项，配置项应该由使用者进行定义
-
二方库应该尽量的简洁，如果必须使用一些三方库，尽量的使用provided引入，例如需要使用lombok，那么使用provided由使用者去进行引入，否则可能会造成版本冲突。