Spring Boot 4.1 + JDK 25 DDD开源脚手架，面向 AI 编程

2026 年，AI 编程已经从”尝鲜”变成了”日常”。
Claude Code、Cursor、Codex CLI 等 Agent 工具越来越强，很多开发者已经习惯了让 AI 帮自己写代码、搭项目、改 Bug。

但用久了就会发现一个痛点：
AI 写代码的质量，高度取决于你给的上下文。
你说”帮我搭一个 SpringBoot 项目”，AI 可能给你整一个三层架构的 CRUD 项目；
你说”按照 DDD 来”，AI 可能给你建了四个包，但领域层里全是 @Entity、@Autowired，四不像；
你说”要多数据源”，AI 可能给你配了两个 DataSource，但事务管理器一塌糊涂。

不是 AI 不行，是你没有给它一个清晰、一致、可参考的工程基准。
AI 就像一个能力很强但缺乏经验的新人，你给它看什么样的代码，它就会写出什么样的代码。

最近在 V2EX 和 GitHub 上看到一个开源脚手架，精准命中了这个痛点，它的核心理念不是”帮你快速搭项目”，而是”给 AI 一个高质量的参考模板，让 AI 生成的代码架构一致、规范统一”。

一、为什么需要一个”面向 AI 编程”的脚手架？

在说脚手架之前，先搞清楚一个问题：传统脚手架和 AI 时代的脚手架，需求已经完全不一样了。

1.1 传统脚手架的痛点

传统脚手架（比如 JHipster、各种 SpringBoot 模板）解决的是”人写代码”的效率问题：

• • 帮你生成基础骨架，少写重复代码；
• • 提供一些通用组件，开箱即用。

但在 AI 编程时代，这些脚手架有几个致命问题：

1. 1. 架构不清晰：三层架构、DDD、贫血模型、充血模型混在一起，AI 学完之后写出来的代码四不像；
2. 2. 规范不统一：命名风格、包结构、异常处理、返回格式各不相同，AI 生成的代码每次都不一样；
3. 3. 技术栈老旧：很多脚手架还停留在 Spring Boot 2.x、JDK 8，AI 学完之后给你用已废弃的 API；
4. 4. 缺乏最佳实践示例：只有空架子，没有完整的业务示例，AI 不知道”正确的写法长什么样”。

1.2 AI 编程时代，脚手架的核心价值变了

AI 编程时代，脚手架不再只是”给人用的模板”，更是**”给 AI 读的参考基准”**。

一个好的 AI 编程脚手架，应该满足：

• • ✅ 架构清晰：分层明确，职责单一，AI 一看就知道代码该放哪；
• • ✅ 规范统一：命名、格式、异常、返回全部标准化，AI 生成的代码一致性高；
• • ✅ 技术栈新：用最新稳定版，AI 不会给你用过时的 API；
• • ✅ 示例完整：有完整的业务示例（用户、订单等），AI 可以照着写；
• • ✅ 约束明确：有清晰的”能做什么、不能做什么”的规则，AI 不会跑偏。

这就是这个 springboot4ddd 脚手架的定位：不只是给你用的，更是给 AI 读的。

二、技术栈解析：Spring Boot 4.1 + JDK 25 到底新在哪？

这个脚手架最显眼的标签就是”最新技术栈”。Spring Boot 4.1 和 JDK 25 到底带来了什么？

2.1 JDK 25 LTS：性能与语法双升级

JDK 25 是 2025 年 9 月发布的 LTS 版本，核心升级包括：

对于企业级应用来说，JDK 25 的核心收益是性能提升 + 更现代的语法，而且作为 LTS 版本，有长期支持，适合生产环境使用。

2.2 Spring Boot 4.1：gRPC 原生支持 + 安全加固

Spring Boot 4.1 于 2026 年 6 月发布，基于 Spring Framework 7.0.x，核心新特性：

Spring Boot 4.1 最低要求 JDK 17，兼容到 JDK 26。脚手架直接用 JDK 25，享受最新特性。

2.3 脚手架完整技术栈

┌─────────────────────────────────────────────┐
│              JDK 25 LTS                     │
│         Spring Boot 4.1                     │
├─────────────────────────────────────────────┤
│  数据访问层                                  │
│  ├── JdbcClient（Spring 原生流畅 API）       │
│  ├── Spring Data JDBC（轻量级 ORM）          │
│  └── MyBatis Plus 3.5.16（复杂 SQL 增强）    │
├─────────────────────────────────────────────┤
│  数据存储                                    │
│  ├── MySQL 8.0（用户域）                     │
│  ├── PostgreSQL 14（订单域）                 │
│  └── Redis 6.0（缓存）                       │
├─────────────────────────────────────────────┤
│  消息队列                                    │
│  └── RocketMQ 5.3（领域事件）                │
├─────────────────────────────────────────────┤
│  安全与规范                                  │
│  ├── Jakarta Validation（参数校验）          │
│  ├── API 签名验证                            │
│  ├── 统一响应格式                            │
│  └── 全局异常处理                            │
└─────────────────────────────────────────────┘

这个技术栈的选择很有讲究：

• • JdbcClient 是 Spring 6.1+ 推出的新 API，比 JdbcTemplate 更流畅、类型更安全，适合 DDD 仓储层；
• • Spring Data JDBC 比 JPA 轻量，没有脏检查、懒加载这些复杂概念，更符合 DDD 的仓储理念；
• • MyBatis Plus 用来处理复杂查询，和 JdbcClient 互补；
• • 双数据源 是 DDD 分域的体现：用户域用 MySQL，订单域用 PostgreSQL，各自独立事务。

三、DDD 四层架构

这个脚手架最核心的价值，就是严格遵循 DDD 四层架构，而且每一层都有清晰的边界约束。

3.1 整体架构图

┌──────────────────────────────────────────────────────┐
│  Interfaces（接口层）                                 │
│  Controller / VO / DTO 转换 / 自定义注解              │
│  职责：接收请求、参数校验、返回响应                    │
├──────────────────────────────────────────────────────┤
│  Application（应用层）                                │
│  Application Service / Command / Query / DTO / Port   │
│  职责：编排领域对象、事务控制、用例流转                │
├──────────────────────────────────────────────────────┤
│  Domain（领域层）                                     │
│  聚合根 / 实体 / 值对象 / 领域服务 / 领域事件 / 仓储接口│
│  职责：核心业务逻辑、业务规则、领域模型                │
├──────────────────────────────────────────────────────┤
│  Infrastructure（基础设施层）                         │
│  仓储实现 / 配置类 / 外部服务客户端 / 消息处理         │
│  职责：技术实现、数据库访问、外部系统集成              │
└──────────────────────────────────────────────────────┘

3.2 领域层：纯净的业务核心

领域层是 DDD 的灵魂，这个脚手架对领域层有严格约束：不依赖任何 Spring 框架。

// ✅ 正确：纯领域模型，无框架依赖
package com.github.microwind.springboot4ddd.domain.model.user;

public class User {
    private final Long id;
    private String name;
    private String email;
    private String phone;

    // 私有构造，强制通过工厂方法创建
    private User(Long id, String name, String email, String phone) {
        this.id = id;
        this.name = name;
        this.email = email;
        this.phone = phone;
    }

    // 静态工厂方法，封装业务规则
    public static User register(UserUniquenessChecker checker,
                                String name, String email, String phone) {
        // 业务校验
        if (checker.existsByEmail(email)) {
            throw new BusinessException("邮箱已被注册");
        }
        return new User(null, name, email, phone);
    }

    // 充血模型：业务方法在实体上
    public void changeEmail(UserUniquenessChecker checker, String newEmail) {
        if (checker.existsByEmail(newEmail)) {
            throw new BusinessException("邮箱已被使用");
        }
        this.email = newEmail;
    }

    public void changePhone(String newPhone) {
        this.phone = newPhone;
    }
}

// ❌ 错误：领域层混入框架注解
@Entity
public class User {
    @Id
    @GeneratedValue
    private Long id;

    @Autowired
    private UserRepository repository;  // 领域层不能依赖仓储
}

这个约束非常关键。AI 看到领域层的代码全是纯 Java，没有 @Entity、@Autowired，它就会明白：领域层是纯净的，技术细节应该放在基础设施层。

3.3 仓储接口与实现的分离

DDD 的一个核心原则是：仓储接口在领域层，实现在基础设施层。

// 领域层：仓储接口，只定义契约
package com.github.microwind.springboot4ddd.domain.repository;

public interface UserRepository {
    User save(User user);
    Optional<User> findById(Long id);
    Optional<User> findByName(String name);
}

// 基础设施层：仓储实现，用 JdbcClient
package com.github.microwind.springboot4ddd.infrastructure.repository.user;

@Repository
@RequiredArgsConstructor
public class UserRepositoryImpl implements UserRepository {

    @Qualifier("userJdbcClient")
    private final JdbcClient jdbcClient;

    @Override
    public User save(User user) {
        jdbcClient.sql("""
            INSERT INTO users (name, email, phone)
            VALUES (:name, :email, :phone)
            """)
            .param("name", user.getName())
            .param("email", user.getEmail())
            .param("phone", user.getPhone())
            .update();
        return user;
    }

    @Override
    public Optional<User> findById(Long id) {
        return jdbcClient.sql("SELECT * FROM users WHERE id = :id")
                .param("id", id)
                .query((rs, rowNum) -> new User(
                        rs.getLong("id"),
                        rs.getString("name"),
                        rs.getString("email"),
                        rs.getString("phone")
                ))
                .optional();
    }
}

这种分离的好处是：领域层只依赖接口，不依赖具体技术实现。
以后想把 JdbcClient 换成 MyBatis、换成 JPA，只需要改基础设施层的实现，领域层一行代码不用动。
AI 看到这个结构，也会明白：接口定义业务契约，实现处理技术细节。

3.4 应用层：用例编排

应用层负责编排领域对象，控制事务，不包含业务规则。

@Service
@RequiredArgsConstructor
public class UserApplicationService {

    private final UserRepository userRepository;
    private final UserUniquenessChecker uniquenessChecker;
    private final DomainEventPublisher eventPublisher;

    @Transactional(transactionManager = "userTransactionManager")
    public UserDTO registerUser(RegisterUserCommand command) {
        // 1. 创建聚合根（工厂方法封装业务规则）
        User user = User.register(
                uniquenessChecker,
                command.getName(),
                command.getEmail(),
                command.getPhone()
        );

        // 2. 持久化
        User saved = userRepository.save(user);

        // 3. 发布领域事件
        eventPublisher.publish(new UserRegisteredEvent(saved.getId()));

        // 4. 返回 DTO
        return UserDTO.from(saved);
    }
}

应用层的代码很”薄”，只做编排，不做业务判断。
业务规则（比如邮箱唯一性校验）在领域层的工厂方法里，应用层只负责调用。

四、多数据源与领域事件

4.1 多数据源：按域拆分，独立事务

这个脚手架最实用的特性之一就是开箱即用的多数据源。
用户域用 MySQL，订单域用 PostgreSQL，各自独立的事务管理器。

数据源配置

@Configuration
public class DataSourceConfig {

    /**
     * 用户域数据源 - MySQL
     */
    @Bean
    @ConfigurationProperties("spring.user.datasource")
    public DataSource userDataSource() {
        return DataSourceBuilder.create().build();
    }

    @Bean
    public JdbcClient userJdbcClient(@Qualifier("userDataSource") DataSource dataSource) {
        return JdbcClient.create(dataSource);
    }

    @Bean
    public PlatformTransactionManager userTransactionManager(
            @Qualifier("userDataSource") DataSource dataSource) {
        return new DataSourceTransactionManager(dataSource);
    }

    /**
     * 订单域数据源 - PostgreSQL
     */
    @Bean
    @ConfigurationProperties("spring.order.datasource")
    public DataSource orderDataSource() {
        return DataSourceBuilder.create().build();
    }

    @Bean
    public JdbcClient orderJdbcClient(@Qualifier("orderDataSource") DataSource dataSource) {
        return JdbcClient.create(dataSource);
    }

    @Bean
    public PlatformTransactionManager orderTransactionManager(
            @Qualifier("orderDataSource") DataSource dataSource) {
        return new DataSourceTransactionManager(dataSource);
    }
}

使用方式

// 用户服务用用户域事务
@Service
@Transactional(transactionManager = "userTransactionManager")
public class UserApplicationService { ... }

// 订单服务用订单域事务
@Service
@Transactional(transactionManager = "orderTransactionManager")
public class OrderApplicationService { ... }

这种按业务域拆分数据源的方式，是 DDD 限界上下文的体现。
每个域有自己的数据库、自己的事务，域之间通过领域事件解耦，而不是数据库关联。

4.2 JdbcClient：Spring 新一代数据库访问 API

JdbcClient 是 Spring 6.1 推出的新 API，比传统的 JdbcTemplate 更流畅、类型更安全：

// 传统 JdbcTemplate 写法
String sql = "SELECT * FROM users WHERE id = ?";
User user = jdbcTemplate.queryForObject(sql, userRowMapper, id);

// 新版 JdbcClient 写法（流畅链式）
User user = jdbcClient.sql("SELECT * FROM users WHERE id = :id")
        .param("id", id)
        .query((rs, rowNum) -> new User(
                rs.getLong("id"),
                rs.getString("name"),
                rs.getString("email")
        ))
        .optional()
        .orElseThrow(() -> new EntityNotFoundException("用户不存在"));

JdbcClient 的优势：

• • 命名参数（:id）而不是问号占位符，SQL 更易读；
• • 流畅的链式 API，不用再写 queryForObject 这种冗长方法；
• • optional() 直接返回 Optional，不用处理 null；
• • 类型安全，减少运行时异常。

4.3 领域事件：基于 RocketMQ 的最终一致性

DDD 架构下，不同域之间不直接调用，通过领域事件解耦。

// 领域事件定义
public record OrderPaidEvent(Long orderId, String orderNo, BigDecimal amount) {}

// 聚合根中记录事件
public class Order extends AggregateRoot {
    private OrderStatus status;

    public void pay() {
        if (this.status != OrderStatus.PENDING) {
            throw new BusinessException("订单状态不允许支付");
        }
        this.status = OrderStatus.PAID;
        // 记录领域事件（聚合根基类提供）
        registerEvent(new OrderPaidEvent(this.id, this.orderNo, this.totalAmount));
    }
}

// 应用服务中发布事件
@Transactional(transactionManager = "orderTransactionManager")
public void payOrder(Long orderId) {
    Order order = orderRepository.findById(orderId)
            .orElseThrow(() -> new EntityNotFoundException("订单不存在"));
    order.pay();
    orderRepository.save(order);
    // 事务提交后发布事件
    eventPublisher.publish(order.getDomainEvents());
}

事件发布后，用户域可以监听 OrderPaidEvent 更新用户积分，库存域可以监听扣减库存，各域独立处理，互不影响。

五、面向 AI 编程

前面讲的都是技术实现，但这个脚手架最独特的价值，是它的**”面向 AI 编程”设计**。

5.1 给 AI 读的代码，比给人读的更重要

脚手架的 README 里有一句话非常精准：

这份代码不只是给你看的，更是给 AI 读的，用来指导 AI 按什么架构来写代码。

传统脚手架关注”人用起来方不方便”，而这个脚手架关注”AI 学完之后写出来的代码对不对”。

它的设计处处体现了这个理念：

• • 每一层都有完整示例：User 聚合根、Order 聚合根、对应的仓储、应用服务、Controller 都有完整实现，AI 可以直接照猫画虎；
• • 反例明确：README 里明确写了”领域层不能有 @Entity、@Autowired“，AI 不会犯这种错；
• • 命名规范统一：XxxRepository（接口）、XxxRepositoryImpl（实现）、XxxApplicationService（应用服务）、XxxCommand（命令），AI 生成的命名一致；
• • 目录结构清晰：四个顶层包 interfaces、application、domain、infrastructure，AI 不会把代码放错地方。

5.2 Agent CLI 编程指南

这个脚手架最贴心的地方，是提供了完整的 Agent CLI 编程指南，告诉你怎么用 Claude Code、Cursor 等工具基于这个脚手架开发。

核心工作流

# 1. 克隆脚手架（sparse-checkout 只拉取需要的目录）
git clone --no-checkout https://github.com/microwind/design-patterns.git
cd design-patterns
git sparse-checkout init --cone
git sparse-checkout set practice-projects/springboot4ddd
git checkout

# 2. 启动 Agent CLI，指定脚手架为参考
claude-code

# 3. 给 AI 的提示词模板
请以 `springboot4ddd` 脚手架作为参考项目，路径：<脚手架路径>
重点参考：
- pom.xml（依赖与技术栈）
- domain/model/user/User.java（领域模型示例）
- infrastructure/repository/user/UserRepositoryImpl.java（仓储实现示例）
- interfaces/controller/UserController.java（接口层示例）

请遵循以下约束：
【架构分层】
- interfaces/：Controller、VO、DTO
- application/：Application Service、Command、Query
- domain/：聚合根、领域服务、仓储接口、领域事件
- infrastructure/：仓储实现、配置、外部服务

【技术规范】
- Spring Boot 4.1 + JDK 25
- 数据访问用 JdbcClient
- 多数据源通过 @Qualifier 指定
- 领域事件通过 DomainEventPublisher 发布
- 领域层不依赖 Spring

请在当前项目中实现：【你的需求】

常用提示词模板

脚手架还提供了针对常见任务的提示词模板：

创建新聚合根：

请参考 User 聚合根的实现，在 domain/model/ 下创建 Product 聚合根：
1. 纯 Java 代码，无 Spring 注解
2. 私有构造 + 静态工厂方法
3. 包含业务规则校验
4. 在 domain/repository/ 创建 ProductRepository 接口

实现仓储层：

请参考 UserRepositoryImpl，在 infrastructure/repository/ 下创建 ProductRepositoryImpl：
1. 使用 JdbcClient
2. 通过 @Qualifier("productJdbcClient") 注入数据源
3. 实现 domain/repository/ProductRepository 接口

这些模板的价值在于：把”怎么跟 AI 沟通”也标准化了，不用每次都重新描述架构约束。

5.3 为什么这能提升 AI 代码质量？

AI 生成代码的本质是”模式匹配 + 上下文学习”。
你给它的参考代码质量越高、约束越明确，它生成的代码就越一致、越规范。

没有参考时，AI 可能：

• • 这次给你三层架构，下次给你 DDD；
• • 这次用 JdbcTemplate，下次用 MyBatis；
• • 这次事务加在 Service，下次加在 Controller。

有了这个脚手架做参考，AI 会：

• • 始终按照四层架构组织代码；
• • 领域层保持纯净，不混入框架注解；
• • 仓储接口在领域层，实现在基础设施层；
• • 统一用 JdbcClient、统一异常处理、统一返回格式。

一致性，就是 AI 编程时代最大的生产力。

六、全文总结

这个 springboot4ddd 脚手架，最打动我的不是它用了多新的技术栈，而是它抓住了 AI 编程时代的核心痛点：
AI 不缺写代码的能力，缺的是清晰、一致、可参考的工程基准。

传统脚手架解决的是”人写代码的效率”，而这个脚手架解决的是”AI 写代码的质量”。
它通过严格的 DDD 四层架构、统一的命名规范、完整的业务示例、明确的约束规则，给 AI 提供了一个高质量的”学习样本”。
再配合 Agent CLI 编程指南和提示词模板，让 AI 生成的代码架构一致、规范统一、不跑偏。

技术栈方面，Spring Boot 4.1 + JDK 25 + JdbcClient + 多数据源 + RocketMQ 领域事件，都是 2026 年企业级开发的主流选择，既新又稳。
DDD 架构方面，领域层纯净、仓储接口与实现分离、应用层薄编排，都是经过验证的最佳实践。

如果你正在转型 AI 编程，或者团队一直在为”AI 写的代码不规范”而头疼，这个脚手架值得一试。
它不一定是最完美的，但它代表了一个方向：AI 时代的工程脚手架，应该为 AI 而设计。

源码地址：https://github.com/microwind/design-patterns/tree/main/practice-projects/springboot4ddd

AI 编程正在深刻改变软件开发的方式，从”人写代码”到”人指挥 AI 写代码”，工程规范和架构设计的重要性不降反升。
后续持续更新 AI 编程实战专栏：DDD 架构落地、Agent CLI 高效工作流、提示词工程、代码审查自动化全套干货。
喜欢 AI 编程、架构设计、SpringBoot 实战内容，欢迎点赞、收藏、关注，持续跟进 AI 时代的后端开发专栏！

admin普通

收藏 海报 链接