大家好，我是飘渺。今天继续更新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>