大家好，我是飘渺。今天继续更新DDD&微服务专栏，本篇主要与大家分享一下在多人团队中如何更好地组织代码和版本控制。
代码仓库分离
首先，看看在多模块多团队的情境下，应该如何合理组织代码。
以Dailymart项目为例，目前的代码组织方式是将所有的业务模块和基础组件都存放在一个代码仓库中，这种做法在小团队中较为常见，而且许多开源微服务脚手架也采用了这种组织结构。
然而，遗憾的是，这种代码组织方式只适合小团队的使用。在涉及多个团队的大型项目中，每个团队负责独立的开发模块时，这样的代码组织结构很可能会引发问题。
在多模块多团队的开发中，每个模块的发布日期和上线范围可能各不相同。为了解决这个问题，通常需要在开发过程中创建多个分支，这导致多个分支版本并存的情况。
这样的情况下，每次上线都需要协调各团队进行分支代码合并。例如，从各自的特性Feature分支合并到一个统一的测试分支，然后从测试分支构建部署镜像进行发布。然而，合并过程中一旦出现代码冲突，就需要找相关人员进行代码合并，这不仅耗时耗力，而且容易出错。（我曾参与过一个多团队项目开发，每次上线都是鸡飞狗跳）
因此，在多团队开发时，我们建议按照业务模块进行代码拆分，将每个业务模块的代码存放在独立的代码仓库中。
这样，尽管各自团队可能仍然存在多分支开发的情况，但不再需要进行统一的合并，从而极大地提高了开发部署的效率。
同时，需要将所有公共组件也放置于一个单独的代码仓库中，业务模块按需引入即可。
接下来以Dailymart为例，介绍一下代码如何拆分：
1、DailyMart项目中包含了用户、订单、购物车、库存、商品等多个模块，这些模块按照普通SpringBoot项目的形式组织代码，并存放在不同的代码仓库中。
2、将基础组件模块dailymart-starter和dailymart-dependencies模块共同放置到另外一个单独的仓库中，业务模块根据需要引入各自需要的组件。
组件版本的统一管理
在大型项目中，需要统一规划依赖组件的版本，在Maven项目中通常通过BOM（Bill Of Materials）来实现。
BOM全称是Bill Of Materials，译作材料清单。BOM本身并不是一种特殊的文件格式，而是一个普通的POM文件，只是在这个POM中，我们罗列的是一个工程的所有依赖和其对应的版本。该文件一般被其它工程使用，当其它工程引用BOM中罗列的jar包时，不用显示指定具体的版本，会自动使用BOM对应的jar版本。
在Dailymart项目中，dailymart-dependencies就是一个BOM，在该文件中定义了项目所需组件的版本。其他模块只需在pom文件的dependencyManagement中引入bom依赖，后面引入定义好的组件时就不再需要指定版本了。
<dependencyManagement>
<dependencies>
<dependency>
<groupId>com.jianzh5</groupId>
<artifactId>dailymart-dependencies</artifactId>
<version>${revision}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
<dependencies>
<dependency>
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
</dependency>
</dependencies>公共组件升级
当项目中有多个公共组件时会出现这样一个问题，每个公共组件定义的版本可能不一样。比如dailymart-common-spring-boot-starter的版本是1.0.0，dailymart-cache-spring-boot-starter的版本是1.0.1，这样就导致项目的依赖管理变得比较混乱。
推荐的解决办法是使用 revision 占位符统一管理基础组件版本。
1、在pom文件中定义属性
<properties>
<revision>2024.0.0-SNAPSHOT</revision>
</properties>2、定义组件时直接使用revision变量作为版本号
<parent>
<groupId>com.jianzh5</groupId>
<artifactId>dailymart-boot</artifactId>
<version>${revision}</version>
</parent>
<artifactId>dailymart-starter</artifactId>3、在bom文件中通过revision占位符引入公共组件
<dependencyManagement>
<dependencies>
<!-- Internal dependencies Start-->
<dependency>
<groupId>com.jianzh5</groupId>
<artifactId>dailymart-common-spring-boot-starter</artifactId>
<version>${revision}</version>
</dependency>
<dependency>
<groupId>com.jianzh5</groupId>
<artifactId>dailymart-ddd-spring-boot-starter</artifactId>
<version>${revision}</version>
</dependency>
</dependencies>
</dependencyManagement>这样，若公共组件需要修改版本，只需修改 revision 变量的值，各组件版本就会统一变更，非常方便。
不过使用这种方式在公共组件模块执行 maven install 或 maven deploy 时会出现问题，推送到maven仓库中的pom文件仍然使用 revision 变量，业务模块无法直接引用。
此时我们需要借助Maven插件 flatten-maven-plugin，使其在 install 或 deploy 时自动将 revision 替换成具体的版本号。
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>flatten-maven-plugin</artifactId>
<version>${maven-flatten.version}</version>
<configuration>
<updatePomFile>true</updatePomFile>
<flattenMode>resolveCiFriendliesOnly</flattenMode>
</configuration>
<executions>
<execution>
<id>flatten</id>
<goals>
<goal>flatten</goal>
</goals>
<phase>process-resources</phase>
</execution>
<execution>
<id>flatten.clean</id>
<goals>
<goal>clean</goal>
</goals>
<phase>clean</phase>
</execution>
</executions>
</plugin>
</plugins>
</build>在pom文件添加此插件后，执行 install 时会生成一个名为 .flattened-pom.xml 的文件，打开文件后可以看到 revision 变量已经全部替换成了具体的版本号。
图片
Maven版本的选择
在将自定义组件推送到maven仓库时，可以选择两种不同版本：Release版本和Snapshot版本。这两者应该如何选择呢？
两者区别的区别如下：
- 如果是Snapshot版本，在mvn deploy时会自动发布到快照版本库中。引入使用快照版本的模块，在不更改版本号的情况下，直接编译打包时，Maven会自动从仓库下载最新的快照版本。
- 如果是Release版本，那么在mvn deploy时会自动发布到正式版本库中。引入正式版本的模块，在不更改版本号的情况下，编译打包时，如果本地已经存在该版本的模块则不会主动去镜像服务器上下载。
简而言之：Release版本是正式版，有bug不能再继续使用这个版本号，需要配合开发方修改版本号；Snapshot版本是快照版，有bug可以继续使用同一版本号，可以自动升级。
如果是内部开发项目，推荐使用Snapshot版本，即定义组件时在版本号后面加上 -SNAPSHOP 标识符，这样搭配上DevOps会非常方便；如果是需要对外发布的组件，还是需要使用Release版本发布。
小结
本文介绍了在多人团队协作中更有效地组织代码和进行版本控制的方法，希望对你有所帮助！
- 代码仓库优化： 建议按业务模块分离代码至独立仓库，提高开发效率。
- 组件版本统一管理： 引入BOM，通过 revision 占位符简化组件版本管理。
- 公共组件版本升级： 推荐使用 revision 占位符集中管理基础组件版本，借助 flatten-maven-plugin 解决版本问题。
- Maven版本选择： 内部项目使用Snapshot版本，外部发布使用Release版本，确保灵活性和稳定性。
