# 第 8 章 · 多项目构建示例

## 目录结构

```
ch08-multi-project-demo/
├── settings.gradle.kts          # ★ 拼装清单 + includeBuild("build-logic")
├── build.gradle.kts             # 根项目（不放业务）
├── build-logic/                 # ★ Convention Plugin 仓库
│   ├── settings.gradle.kts
│   ├── build.gradle.kts         # 应用 kotlin-dsl
│   └── src/main/kotlin/
│       └── shop.java-conventions.gradle.kts   # 共享构建约定
├── app/                         # 启动模块
│   ├── build.gradle.kts
│   └── src/main/java/com/shop/ShopApp.java
├── feature-user/                # 用户业务
├── feature-order/               # 订单业务（依赖 user）
└── lib-core/                    # 公共领域模型
```

## 跑起来

```bash
# 看有哪些子模块
./gradlew projects

# 编译所有
./gradlew build

# 单独构建一个模块（更快）
./gradlew :feature-order:build

# 查看模块依赖树
./gradlew :feature-order:dependencies --configuration runtimeClasspath

# 启动 app
./gradlew :app:run

# 调试 build-logic：先看它的 task
./gradlew -p build-logic tasks
```

## 看点

1. **build-logic** 通过 `includeBuild` 在 settings 里被引入 →
   子模块用 `plugins { id("shop.java-conventions") }` 即可继承所有约定。
2. **跨模块依赖** 用 `implementation(project(":lib-core"))` 而不是 jar/maven 坐标。
3. **每个子模块** 都极薄 —— 因为公共逻辑都被 Convention Plugin 收编了。
4. **变更范围** —— 改 `feature-user` 不会编译 `feature-order` 的 jar；
   只有 `lib-core` 的改动会触发下游全链路重编。