当前位置：首页 > news >正文

DDD 架构重构实践：AI Skills 如何赋能DDD设计与重构

news 2026/8/4 13:50:47

一、重构背景：从个人到团队的规范重心转移
二、cleanddd-skills 实践：四个模块的体验
- 2.1 requirements-analysis：需求结构化的起点
- 2.2 modeling：聚合边界的确定
- 2.3 dotnet-init：技术栈限制的发现
- 2.4 dotnet-coding：实现阶段
三、技术栈局限性的破解思路
四、总结

一、重构背景：从个人到团队的规范重心转移

最近工作中遇到了一个典型场景：需要将现有的 MVC 架构项目重构为 DDD 架构。说实话，如果是自己一个人负责统筹，其实对具体风格或规范不会太在意——毕竟没有沟通成本，怎么顺手怎么来。但现在在团队里，情况就不一样了，必须重新重视起规范问题。

正好看到一篇推文介绍了cleanddd-skills这个工具，想着来看看有什么可以学习的地方。这其实是一个典型的 AI Agent 技能包，通过结构化的方式引导完成 CleanDDD 实践的四个阶段：需求分析、领域建模、项目初始化和代码实现。对于后端开发来说，这种规范化的工具正好能解决团队协作中的沟通成本问题。

二、cleanddd-skills 实践：四个模块的体验

2.1 requirements-analysis：需求结构化的起点

cleanddd-requirements-analysis模块的核心职责，是把需求整理为结构化描述，转换为模型易于理解的清晰描述。换句话说，它负责把散乱的自然语言需求，转化为后续建模可以直接使用的输入。

我用 ruoyi 作为测试项目，在调用这个模块后，Agent 首先让我描述需求，我给出的描述是：“需要把整个测试项目转化为 DDD 架构”。

生成的计划内容包括干系人分析、需求拆分、实体归类、后续动作、业务规则与依赖等。从输出来看，这个模块确实把原本散乱的需求进行了系统化整理。

但在实践过程中，我心里产生了一个疑问：这个部分已经完成了限界上下文的划分吗？毕竟限界上下文是 DDD 中的核心概念，如果能在需求分析阶段就完成划分，后续的建模工作会更有方向性。带着这个疑问，我继续进入了 modeling 阶段。

2.2 modeling：聚合边界的确定

cleanddd-modeling模块负责将结构化需求描述转换为系统模型结构，重点在于确定聚合的边界、事件、定时任务等。

对于后端开发者来说，我个人的理解是：这个过程类似于通过 ER 图进行数据建模，找出聚合根，然后把零散的元素分类到各自的聚合中。本质上，这就是在确定"边界"——哪些行为应该归属于哪个聚合，哪些变化应该表达为命令，哪些变化应该表达为事件。

从输出来看，这一步直接进行了聚合设计划分和 API 设计。有意思的是，从生成的限界上下文划分图可以看出，限界上下文的划分其实是在 requirements-analysis 阶段就已经完成的，modeling 阶段是基于这个划分结果继续深入，确定聚合边界和 API 设计。

这验证了我之前的疑问：analysis 阶段的结构化输出中，确实包含了限界上下文的划分结果，而 modeling 阶段是在这个基础上进行更细致的聚合设计和 API 定义。这个分工很合理——先确定大的边界（限界上下文），再确定小的边界（聚合），最后才是具体的行为定义。

2.3 dotnet-init：技术栈限制的发现

cleanddd-dotnet-init模块负责新工程初始化，使用 NetCorePal 模板创建项目骨架。但这里遇到了一个问题：被告知"只能用在 .Net 中"。

简单了解了一下 NetCorePal，这个框架是保证项目结构和落地质量的，它在 CleanDDD 实践中承担的是"工程承载"的角色。也就是说，前面的 requirements-analysis 和 modeling 更偏分析和设计，到了 dotnet-init，框架开始把这些结果带到实际工程里。

但问题来了：如果我的项目是 Java 技术栈呢？这个框架就成了技术栈壁垒。这时候我开始思考：NetCorePal 在 CleanDDD 过程中扮演什么角色？它是不可替代的吗？如果它的核心价值只是"工程承载"，那么理论上任何能承载模型到代码映射的框架都可以替代它。

2.4 dotnet-coding：实现阶段（跳过）

cleanddd-dotnet-coding模块负责将之前的设计落地为代码实现。不过我决定跳过这一步，因为设计到这里已经完毕了，剩下的是框架做的具体实现，已经和本文无关。

其实从实践角度来说，设计和代码实现之间的跨度往往是最难跨越的。如果前面的需求分析、领域建模做扎实了，代码实现反而是水到渠成的事情。本文的重点是设计和工具使用体验，不需要深入到代码层面。

三、技术栈局限性的破解思路

遇到 .NET 框架的限制后，我开始系统性地思考如何破解这个问题。这其实是一个通用的方法论问题：当你发现一个好工具无法直接使用时，应该怎么分析和寻找替代方案？

第一步：分析框架的核心职责

NetCorePal 在 CleanDDD 过程中承担的是"工程承载"职责。它做的事情包括：

使用模板初始化项目
确定解决方案和工程结构
确定基础技术选项
为聚合、命令、事件、查询、Endpoint 等实现准备对应位置

本质上，它把前面分析和设计阶段的结果，映射到了具体的工程结构中。那么，这个职责是框架独有的吗？显然不是。任何成熟的 Java 框架都可以承担这个角色。

第二步：评估框架的不可替代性

如果 NetCorePal 的核心价值是"提供 CleanDDD 最佳实践的工程模板"，那么在 Java 生态中肯定有对应的替代方案。我需要找的是一个能满足以下条件的框架：

支持 DDD 分层架构
提供清晰的领域模型承载方式
有成熟的工程模板和脚手架

第三步：寻找替代品

在 Java 生态中，我最终找到了 COLA（Clean Object-oriented and Layered Architecture），这是阿里出品的一个应用架构框架。它同样强调分层架构和领域模型，并且在工程承载方面做得很好。更重要的是，社区里已经有基于 COLA 的 AI Skill——cola-skill。

实践验证下来，用 cola-skill 替换 dotnet-init 后，项目结构没有问题，代码只需要微调一下。这说明框架不是不可替代的，关键在于理解它在 CleanDDD 过程中的定位。