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

目录一、重构背景从个人到团队的规范重心转移二、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 生态中我最终找到了 COLAClean Object-oriented and Layered Architecture这是阿里出品的一个应用架构框架。它同样强调分层架构和领域模型并且在工程承载方面做得很好。更重要的是社区里已经有基于 COLA 的 AI Skill——cola-skill。实践验证下来用 cola-skill 替换 dotnet-init 后项目结构没有问题代码只需要微调一下。这说明框架不是不可替代的关键在于理解它在 CleanDDD 过程中的定位。四、总结这次实践的体验简单来说是还可以。因为语言问题体验确实差强人意但通过使用别的 skills 很好地弥补了这一点。这让我意识到了一个关键洞察设计与实现分离的价值。如果设计和实现在同一个 skill 中语言栈会成为硬性限制。比如如果 cleanddd-skills 把四个阶段打包在一起那我就无法在 Java 项目中使用它。但现在分开了requirements-analysis 和 modeling 阶段是技术栈无关的可以用在任何语言项目中dotnet-init 和 dotnet-coding 阶段是技术栈相关的可以选择对应的 Java 框架 skill这种分离带来的灵活性对于多技术栈的团队来说尤为重要。设计阶段可以统一使用一个 skill保证团队内部的设计语言一致性实现阶段可以根据各自的技术栈选择对应的 skill既保证了设计规范的统一又不限制技术选型的灵活性。如果正常开发的话后续的计划是使用 cola-skill 完成代码落地微调细节。而这次实践也留下了一个思考需求分析和建模阶段的边界划分标准如何在不同团队中统一这可能需要结合团队的具体业务场景和技术栈制定更细化的规范。参考资料原文链接https://mp.weixin.qq.com/s/5pFRx2jv_M4HEKATejjTvgcleanddd-skills 项目https://github.com/netcorepal/cleanddd-skills