2. 多模块项目结构：Maven/Gradle/Go Module/Python虚拟环境下的多模块组织方式、模块间依赖关系图

企业级业务系统通常采用多模块架构来分离关注点、提升编译并行度并实现复用。不同技术栈的多模块组织方式差异显著，但核心目标一致：明确模块边界、管理依赖版本、控制编译顺序。本章从四种主流构建工具出发，对比其多模块组织方式，并绘制模块间依赖关系图。

2.1 多模块项目核心概念

多模块项目（Multi-Module Project）将一个单体仓库（Monorepo）拆分为多个独立模块，每个模块拥有自己的构建配置，但共享父级或根配置。模块间通过显式声明依赖形成有向无环图（DAG），构建工具据此确定编译顺序。

2.2 Maven 多模块组织

Maven 通过 <parent> 和 <modules> 实现多模块。根 POM 声明子模块列表，子模块通过 <parent> 指向根 POM，继承版本号和插件配置。

<!-- 根 pom.xml -->
<project>
  <groupId>com.enterprise</groupId>
  <artifactId>my-system</artifactId>
  <version>1.0.0</version>
  <packaging>pom</packaging>
  <modules>
    <module>common</module>
    <module>service-api</module>
    <module>service-impl</module>
    <module>web</module>
  </modules>
</project>

<!-- service-impl/pom.xml -->
<project>
  <parent>
    <groupId>com.enterprise</groupId>
    <artifactId>my-system</artifactId>
    <version>1.0.0</version>
  </parent>
  <artifactId>service-impl</artifactId>
  <dependencies>
    <dependency>
      <groupId>com.enterprise</groupId>
      <artifactId>service-api</artifactId>
      <version>${project.version}</version>
    </dependency>
    <dependency>
      <groupId>com.enterprise</groupId>
      <artifactId>common</artifactId>
    </dependency>
  </dependencies>
</project>

2.3 Gradle 多模块组织

Gradle 使用 settings.gradle 声明子模块，子模块通过 build.gradle 中的 project() 或 api/implementation 声明依赖。Gradle 支持配置即代码，依赖管理更灵活。

// settings.gradle
rootProject.name = 'my-system'
include 'common', 'service-api', 'service-impl', 'web'

// service-impl/build.gradle
dependencies {
    implementation project(':service-api')
    implementation project(':common')
    // 使用 api 声明时，依赖会传递
    api 'com.google.guava:guava:31.1-jre'
}

2.4 Go Module 多模块组织

Go 从 1.11 起引入 go.mod 原生支持多模块。企业项目中常采用 Monorepo 模式，每个子目录拥有独立 go.mod，通过 replace 指令实现本地模块引用。

# 项目目录结构
my-system/
├── go.work          # Go 1.18+ 工作区，统一管理多个模块
├── common/
│   └── go.mod       # module my-system/common
├── service-api/
│   └── go.mod       # module my-system/service-api
├── service-impl/
│   └── go.mod       # module my-system/service-impl
└── web/
    └── go.mod       # module my-system/web

// service-impl/go.mod
module my-system/service-impl

go 1.21

require (
    my-system/common v0.0.0
    my-system/service-api v0.0.0
)

replace (
    my-system/common => ../common
    my-system/service-api => ../service-api
)

2.5 Python 虚拟环境多模块组织

Python 通过虚拟环境（venv）隔离依赖，多模块组织通常结合 setuptools 或 poetry 实现。每个模块作为独立包，通过 pip install -e 可编辑模式安装，实现本地模块引用。

# 项目目录结构
my-system/
├── pyproject.toml       # 根项目配置
├── common/
│   ├── pyproject.toml   # 独立包配置
│   └── src/
│       └── common/
│           └── __init__.py
├── service-api/
│   ├── pyproject.toml
│   └── src/
│       └── service_api/
│           └── __init__.py
└── service-impl/
    ├── pyproject.toml
    └── src/
        └── service_impl/
            └── __init__.py

# service-impl/pyproject.toml
[build-system]
requires = ["setuptools", "wheel"]
build-backend = "setuptools.build_meta"

[project]
name = "service-impl"
version = "0.1.0"
dependencies = [
    "common @ file://../common",
    "service-api @ file://../service-api",
]

2.6 模块间依赖关系图

以下 SVG 图展示了一个典型企业业务系统的模块依赖关系，包含四个核心模块：common（基础工具）、service-api（接口定义）、service-impl（业务实现）、web（HTTP 层）。

2.7 四种构建工具对比

2.8 模块拆分最佳实践

根据企业业务系统经验，推荐以下模块拆分策略：

1. 按业务能力拆分：每个模块对应一个业务域（如订单、支付、库存），避免跨域耦合。
2. 接口与实现分离：定义 service-api 模块存放接口和 DTO，service-impl 模块存放实现，便于接口稳定、实现灵活替换。
3. 公共模块下沉：将工具类、通用异常、基础实体放入 common 模块，被所有业务模块依赖。
4. 模块粒度适中：模块数量建议控制在 5~20 个，过多会导致构建管理复杂，过少则失去多模块优势。