夜雨聆风带领团队转型AI编程模式已快一年，从工具到工程，从rules到SDD。团队尝试了很多改变，有失败有成功。今天和大家聊一聊项目工程架构这块的一些思考和改变。
随着单体效率指数级增加，我认为未来最适合 AI 编程的工程架构，不是“大而全单体”，也不是一上来就微服务，而是：
以领域模块为核心的“模块化单体 + 清晰分层 + 可演进微服务”的架构。
更具体一点：
Spring Boot + DDD 轻量化领域建模 + Spring Modulith/多模块 Maven + 六边形架构思想 + 强测试/强文档/强边界约束。
这类架构最适合 AI，不是因为它最时髦，而是因为它最符合 AI 编程的三大前提：
上下文可理解、改动边界可控制、结果可验证。
一、AI 最怕的不是代码多，而是“边界混乱”
传统工程里，很多 Java 项目长这样：
controller service mapper entity dto vo utils config
看起来很清爽，其实对 AI 很不友好。
因为这种结构是技术分层，不是业务分层。AI 进来以后，很容易出现几个问题：
第一，它不知道“会员充值”“订单结算”“助教排课”“优惠核销”之间的业务边界在哪里。
第二，它改一个 service，可能牵动一堆 mapper、utils、common 方法，最后像扯毛衣线头，一拽一大片。
第三，它看似生成了代码，但很难判断有没有破坏业务规则。
所以未来 AI 编程时代，工程架构的核心不是“让人觉得规范”，而是要让 AI 能够快速回答三个问题：
我在哪个业务上下文里？ 我能改哪些文件？ 我改完怎么证明没错？
这就是“AI 友好型架构”的本质。
二、为什么不是直接微服务？
很多人会本能地说：既然 AI 能写代码，那未来是不是更适合微服务？
我反而觉得：大部分中小团队，尤其是业务还在快速变化的团队，不应该一开始就微服务。
微服务的优势包括强模块边界、独立部署、技术多样性，但同时也带来分布式系统复杂度、最终一致性、运维和测试成本等问题。很多团队会发现，微服务反而成为生产力负担。
这点对 AI 编程尤其关键。
AI 可以帮你写代码，但它不能替你消除分布式复杂度。比如：
服务 A 调用服务 B 服务 B 发 MQ 服务 C 消费后更新状态 服务 D 再做结算 中间某一步失败了
这时候 AI 要理解的不是一个类、一个模块，而是一条跨服务、跨数据库、跨消息队列的业务链。上下文越分散，AI 越容易“看懂局部，误判全局”。
所以微服务不是不能用，而是要等到业务边界、团队边界、部署边界都成熟后再拆。
这很像《孙子兵法》里讲的：胜兵先胜而后求战，败兵先战而后求胜。
架构也是如此。
先在单体里把边界打清楚，再拆服务；不要边界还糊着，就上微服务战场。
三、为什么模块化单体更适合 AI 编程？
Spring 官方的 Spring Modulith 项目，正是围绕这个方向展开的。它的定位是帮助开发者构建“领域驱动的模块化 Spring Boot 应用”，让应用按照功能模块组织，并支持模块边界验证、单模块集成测试、模块级行为观察和文档生成。
这些能力，对 AI 编程非常重要。
1. 模块边界清楚，AI 更容易定位上下文
比如某 SaaS 系统，不应该是这样：
controller service mapper entity dto
更适合这样：
club member order recharge coach booking payment settlement marketing inventory
每个模块内部再有自己的 controller、application、domain、infrastructure。
AI 接到任务：“帮我修改会员充值时赠送金额的计算逻辑。”
它就能快速定位：
recharge member payment
而不是在全局 service 目录里乱翻。
这对 AI 来说非常重要。现在主流 AI 编程 Agent，例如 GitHub Copilot coding agent、OpenAI Codex、Claude Code，本质上都需要读取仓库、理解上下文、执行修改、运行测试，然后提交 PR 或变更建议。
也就是说，未来工程不是只给“人”看的，也是给“AI 工友”看的。
2. 单体部署降低复杂度，模块化又保留演进能力
模块化单体有一个妙处：运行时是一个应用，设计时是多个业务模块。
它不像传统单体那样所有业务糊成一锅粥，也不像微服务那样一开始就引入服务发现、链路追踪、分布式事务、网关、配置中心、灰度发布等复杂体系。
这对 AI 很友好，因为 AI 最擅长处理的是：
清晰目标 + 有限上下文 + 明确约束 + 自动验证
而不是：
模糊边界 + 分布式链路 + 隐性规则 + 人肉对账
3. 模块化单体天然适合“以后拆微服务”
你可以先这样做：
tmall-billiard-app ├── member ├── order ├── payment ├── booking ├── coach ├── settlement └── marketing
等到某个模块确实变复杂，比如支付结算需要独立扩展，再拆出去：
payment-service settlement-service
这种拆法是“顺藤摸瓜”，不是“凭空切肉”。
如果模块内边界已经清楚，AI 后续辅助拆服务会更可靠。因为它能识别模块的 public API、领域事件、数据库依赖、测试用例和调用关系。
反过来，如果原来就是一堆 service 互相乱调，AI 拆出来的服务大概率会变成“分布式屎山”。
以前是一个锅里炖，现在是十个锅里炖，味道还互相串。
四、推荐的友好工程结构
建议采用下面这种结构：
billiard-saas ├── app-bootstrap │ └── 启动类、全局配置、权限配置、任务调度入口 │ ├── modules │ ├── member │ │ ├── api │ │ ├── application │ │ ├── domain │ │ ├── infrastructure │ │ └── README.md │ │ │ ├── order │ │ ├── api │ │ ├── application │ │ ├── domain │ │ ├── infrastructure │ │ └── README.md │ │ │ ├── payment │ ├── booking │ ├── coach │ ├── settlement │ └── marketing │ ├── shared-kernel │ ├── common │ ├── exception │ ├── id │ ├── money │ ├── tenant │ └── security │ ├── specs │ ├── architecture.md │ ├── domain-map.md │ ├── ai-coding-guide.md │ └── decision-records │ ├── .claude │ ├── skills │ └── commanads │ │── .mcp.json │── CLAUDE.MD │── AGENTS.MD │ └── pom.xml
每个业务模块内部建议这样分：
order ├── api │ ├── OrderController.java │ ├── request │ └── response │ ├── application │ ├── OrderAppService.java │ ├── command │ ├── query │ └── assembler │ ├── domain │ ├── model │ ├── service │ ├── event │ └── repository │ └── infrastructure ├── persistence ├── mapper ├── integration └── mq
核心思想是：
api：对外入口 application：编排业务流程 domain：放真正业务规则 infrastructure：数据库、MQ、三方接口
这比传统贫血模型更适合 AI。因为 AI 一看就知道：
修改接口参数，去 api。
修改流程编排，去 application。
修改核心规则，去 domain。
修改 SQL 和外部依赖，去 infrastructure。
这叫“各归其位”。
儒家讲“君君、臣臣、父父、子子”，放在工程里就是：
Controller 不要干 Service 的活，Service 不要干 Domain 的活，Domain 不要偷偷依赖数据库。
五、AI 友好架构的 8 条硬标准
未来 Java 工程要适配 AI 编程，至少要满足这 8 条。
1. 按业务模块组织，而不是按技术层组织
不推荐：
controller/order controller/member service/order service/member mapper/order mapper/member
推荐：
order/api order/application order/domain order/infrastructure
原因很简单：AI 接任务时，通常是按业务意图理解，而不是按技术层理解。
你不会对 AI 说：帮我改一下 service 层第 243 行。
你会说：帮我调整充值活动的首充优先规则。
所以工程结构也应该顺着业务语言长出来。
2. 每个模块必须有 README
例如：
modules/recharge/README.md
里面写清楚：
模块职责 核心业务流程 核心领域对象 外部依赖 不能做什么 常见修改点 测试命令
这不是装饰品，而是 AI 的“作战地图”。
未来优秀工程和普通工程的差距，不只在代码，还在“AI 能不能快速读懂”。
3. 使用 copilot-instructions.md / AGENTS.md / CLAUDE.md
建议仓库里放这些文件：
.github/copilot-instructions.md AGENTS.md CLAUDE.md docs/ai-coding-guide.md
内容包括：
项目架构说明 模块边界规则 命名规范 异常处理规范 事务规范 DTO/DO/PO/VO 使用规则 单元测试要求 禁止事项 常用命令
未来不是“谁 prompt 写得好谁厉害”，而是：
谁的工程上下文沉淀得好，谁的 AI 产出稳定。
4. 强测试，尤其是模块级测试和业务规则测试
AI 写代码最大的问题不是“不会写”，而是“写得像对，其实错”。
所以 AI 友好型工程必须有测试兜底：
domain unit test application integration test repository test contract test architecture test
尤其是业务规则测试。
比如充值规则：
首充活动优先 普通活动按赠送金额最大 同等优惠按创建时间 活动必须在有效期内 活动必须匹配门店/卡类型/租户
这些规则不能只藏在需求文档里，必须变成测试。
@Test void should_choose_first_recharge_rule_when_user_has_no_recharge_record() { // given // when // then }
AI 改完代码后，只要测试跑不过，就知道错了。
这就像王阳明讲“知行合一”。代码里的“知”，不是写在 PPT 上的需求理解；代码里的“行”，就是测试能不能过。
没有测试的 AI 编程，就是“口头心学”，看起来顿悟，其实一上线就破功。
5. 业务规则进入 domain，而不是堆在 service
很多 Java 项目最容易写成这样：
public void recharge(RechargeReq req) { // 查会员 // 查卡 // 查活动 // 判断首充 // 判断金额 // 计算赠送 // 写订单 // 写流水 // 调支付 // 发消息 }
这个方法人看着都头大，AI 看了更容易幻觉。
更好的方式是：
RechargeAppService：编排流程 RechargePolicy：选择规则 RechargeOrder：表达充值订单 RechargeGiftCalculator：计算赠送 MemberRechargeHistory：判断是否首充
AI 修改“赠送规则”时，就去改 RechargeGiftCalculator 或 RechargePolicy，而不是在 500 行 service 里动刀。
6. 模块之间禁止直接互调内部实现
模块之间应该通过：
公开接口 领域事件 应用服务 facade 防腐层
而不是：
orderService 直接调用 memberMapper paymentService 直接查 order 表 marketingService 直接改 member_balance
这个规则对 AI 极其重要。
因为 AI 很容易为了完成任务，走“最短路径”：
既然我要查会员余额，那我直接注入 MemberMapper 吧。
短期能跑，长期边界烂掉。
所以要通过架构测试、包可见性、Spring Modulith 模块验证等方式限制它。
7. 数据库也要按模块边界治理
很多项目代码看似分模块，数据库却全员裸奔：
任何模块都可以查任何表 任何 service 都可以 update 任意字段
这对 AI 很危险。
推荐：
member 模块只拥有 member_* 表 order 模块只拥有 order_* 表 payment 模块只拥有 payment_* 表 settlement 模块只拥有 settlement_* 表
跨模块读取可以通过：
查询接口 只读视图 领域事件同步的读模型 CQRS 派生表
尤其是订单、支付、结算、账务这类核心链路，不要让 AI 随便跨表 update。否则它会非常勤快地帮你“修 bug”，顺手把账修歪。
8. 架构规则要自动化检查
未来 AI 编程中，靠人肉 code review 不够。
要把规则变成机器能检查的东西：
Checkstyle Spotless ArchUnit Spring Modulith verify Maven Enforcer SonarQube Jacoco GitHub Actions Testcontainers
例如：
controller 不能直接访问 mapper domain 不能依赖 infrastructure order 模块不能访问 member.infrastructure application 层事务必须显式标注 核心金额计算必须有单元测试
AI 是个很强的“工匠”，但它也像刚入职的天才实习生：
手快，胆大，偶尔犯傻。
你不能只靠“相信它”，你要给它轨道、护栏和红绿灯。
六、最终建议
不要追求“最先进架构”，要追求“最适合 AI 与人协作的架构”。
AI 时代的好架构，不是让代码看起来有多高级，而是让业务边界清楚到让AI 不容易犯傻，让规则沉淀到测试里，让每一次改动都有证据可循。
这其实也像毛选里讲的“建立根据地”。
微服务是远征军，模块化单体是根据地。 根据地不稳，远征越远，败得越快。 先把业务模块、规则、测试、文档这些“群众基础”扎牢，AI 编程才不是游击队乱窜，而是真正进入有组织、有纪律、有战斗力的工程化生产。
