综合设计：微服务骨架的目录与依赖规范（父 POM 模块划分）

项目一多就会乱：版本各写各的、公共代码复制粘贴、服务间直接依赖对方内部类。本章给出可直接照抄的多模块骨架：父 POM 统一版本，契约模块统一接口，服务模块只写业务。版本锚点同第 01 章：Spring Boot 3.5.x + Spring Cloud 2025.0.x + spring-cloud-alibaba 2025.0.0.x（补丁号以官方为准）。

模块划分

mall-parent                    父工程（packaging=pom，只管版本与模块）
├── mall-common                公共模块：统一返回/异常/工具，无业务
├── mall-gateway               网关服务（可执行）
├── order-service              订单服务（可执行）
├── stock-service              库存服务（可执行）
├── order-api                  契约模块：order 对外暴露的 Feign 接口与 DTO
└── stock-api                  契约模块：stock 对外暴露的 Feign 接口与 DTO

核心规范：服务间只依赖“契约模块（api）”，禁止依赖对方内部实现；order-service 依赖 stock-api 完成远程调用，运行期仍走注册发现。

父 POM：版本唯一来源

<project>
  <modelVersion>4.0.0</modelVersion>
  <parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>3.5.0</version>     <!-- 补丁号按官方兼容矩阵取最新 -->
    <relativePath/>
  </parent>
  <groupId>com.example</groupId>
  <artifactId>mall-parent</artifactId>
  <version>1.0.0-SNAPSHOT</version>
  <packaging>pom</packaging>
  <modules>
    <module>mall-common</module>
    <module>order-api</module>
    <module>stock-api</module>
    <module>order-service</module>
    <module>stock-service</module>
    <module>mall-gateway</module>
  </modules>
  <properties>
    <java.version>17</java.version>
    <spring-cloud.version>2025.0.0</spring-cloud.version>
    <spring-cloud-alibaba.version>2025.0.0.0</spring-cloud-alibaba.version>
  </properties>
  <dependencyManagement>
    <dependencies>
      <!-- 统一管理 Spring Cloud 全家桶，子模块不写版本号 -->
      <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-dependencies</artifactId>
        <version>${spring-cloud.version}</version>
        <type>pom</type>
        <scope>import</scope>
      </dependency>
      <!-- 统一管理 Spring Cloud Alibaba 组件 -->
      <dependency>
        <groupId>com.alibaba.cloud</groupId>
        <artifactId>spring-cloud-alibaba-dependencies</artifactId>
        <version>${spring-cloud-alibaba.version}</version>
        <type>pom</type>
        <scope>import</scope>
      </dependency>
    </dependencies>
  </dependencyManagement>
</project>

配套插件放父 POM 的 pluginManagement：spring-boot-maven-plugin 只配给可执行服务模块（repackage + 分层 jar）；maven-compiler-plugin 锁 Java 17。契约/公共模块不 repackage，产出普通 jar。

服务模块目录规范

order-service/src/main/java/com/example/order/
├── OrderApplication.java      启动类（放包根，保证组件扫描覆盖全包）
├── controller/                HTTP 接入层
├── application/               应用服务：用例编排与事务边界
├── domain/                    领域模型与仓储接口（按 DDD 取舍）
├── infrastructure/            Feign 客户端、MQ、仓储实现
├── config/                    本服务配置类
└── common/                    服务内部通用件（不放业务）

依赖方向只允许向下：controller → application → domain ← infrastructure，禁止反向；业务异常统一由全局异常处理器转错误码响应。

依赖规范要点

• 子模块一律不写 Spring Cloud/Alibaba 组件版本，全部由父 POM 的 dependencyManagement 兜底。
• 服务模块依赖被调方契约而非其实现，如 order-service 引 stock-api（坐标 <groupId>com.example</groupId>、<artifactId>stock-api</artifactId>），配合 spring-cloud-starter-openfeign 使用。
• 契约模块只放 Feign 接口、请求/响应 DTO 与错误码常量，不引 spring-boot-web、不含实现。
• mall-common 只放无业务倾向的通用件；一旦长出业务代码，立即下沉到对应契约/领域。

强制与校验

用 Maven Enforcer 插件禁止依赖冲突、强制 JDK 版本；CI 加“禁止 service 模块依赖 api 之外模块”的检查；新增服务/契约走评审，先答三问：契约定了吗、数据归属清楚吗、会不会循环依赖。

小结

骨架的价值是把规范变成结构：父 POM 锁版本、契约模块锁接口、分层目录锁依赖方向。照此搭建后，新增服务 = 新建模块 + 声明契约依赖 + 实现领域逻辑，团队协作与持续集成的摩擦大幅下降。