登录
/
注册
首页
论坛
其它
首页
科技
业界
安全
程序
广播
Follow
关于
导读
排行榜
资讯
发帖说明
登录
/
注册
账号
自动登录
找回密码
密码
登录
立即注册
搜索
搜索
关闭
CSDN热搜
程序园
精品问答
技术交流
资源下载
本版
帖子
用户
软件
问答
教程
代码
写记录
写博客
小组
VIP申请
VIP网盘
网盘
联系我们
发帖说明
道具
勋章
任务
淘帖
动态
分享
留言板
导读
设置
我的收藏
退出
腾讯QQ
微信登录
返回列表
首页
›
业界区
›
业界
›
DDD难落地?就让AI干吧! - cleanddd-skills介绍 ...
DDD难落地?就让AI干吧! - cleanddd-skills介绍
[ 复制链接 ]
跑两獗
昨天 05:54
猛犸象科技工作室:
网站开发,备案域名,渗透,服务器出租,DDOS/CC攻击,TG加粉引流
DDD 这些年一直有点尴尬。
知道它有价值的人不少,真正愿意照着它的方式把需求、模型、结构和代码一步一步做下来的人并不多。最常见的印象也差不多:概念多、步骤多、层次多,看起来像是把原本能直接写出来的业务系统,又绕了一圈。
这个判断里有误解,也有现实原因。
误解在于,很多时候被嫌“繁琐”的部分,恰恰是业务系统要做稳、做久、做清楚本来就需要的动作。
现实原因在于,如果手里没有合适的框架和方法,这些动作确实很难坚持,最后就会变成:理念知道一点,工程做成另外一套。
工具层面,NetCorePal 解决了框架和工程承载的问题。具体到实操层面,现在有了 AI,这件事开始变得简单起来。我们把 CleanDDD 实践里需要遵守和执行的核心原则整理成 skills,让 AI Agent 能沿着固定顺序参与需求分析、领域建模、项目初始化和代码实现。由于 CleanDDD 本身的原则和方法都非常明确、可执行,AI Agent 参与进来会比较自然,整个过程也更容易组织起来。
于是就有了 cleanddd-skills。
cleanddd-skills 包含哪些内容
cleanddd-skills 主体由四个部分组成:
cleanddd-requirements-analysis
cleanddd-modeling
cleanddd-dotnet-init
cleanddd-dotnet-coding
这四个部分分别处理四类事情:
requirements-analysis 负责把需求整理成结构化描述。
modeling 负责把结构化需求描述转换成系统模型结构。
dotnet-init 负责在需要时,根据模型结果初始化新的工程骨架。
dotnet-coding 负责在需求、模型和工程结构已经明确的基础上继续完成实现。
如果是新工程,通常会按完整链路使用:
requirements-analysis -> modeling -> dotnet-init -> dotnet-coding
如果已经有工程,可以直接使用:
requirements-analysis -> modeling -> dotnet-coding
cleanddd-skills 的重点,不在于把四个 skill 摆在那里,而在于把实践 CleanDDD 的过程组织成一条前后连续的流程。
requirements-analysis
cleanddd-requirements-analysis 只处理需求本身,不进入建模,也不进入代码。
这一部分的任务,是把原始需求整理成后面能继续使用的结构化描述。通常会涉及这些内容:
干系人是谁
业务对象有哪些
每条需求归属于哪个对象
哪些是动作,哪些是状态,哪些是约束
哪些触发会引出后续行为
哪些依赖关系是显性的,哪些关系藏在描述背后
这一部分体现的 CleanDDD 实践重点很明确:先用业务语言把问题说明白,再进入模型语言。
如果需求阶段还是散乱的自然语言,后面的建模就很容易依赖临时理解。
而 requirements-analysis 做的,就是把这些输入先整理成适合建模的形式。
这一部分的产出,不是为了写一份好看的文档,而是为了给 modeling 提供明确输入。
modeling
cleanddd-modeling 接在 requirements-analysis 后面,负责把结构化需求描述继续转换成系统模型结构。
这一部分通常会整理出:
聚合
命令
事件
查询
API Endpoint
定时任务
这一部分的工作重点,不是解释术语,而是确定结构和归属。
哪些行为进入哪个聚合。
哪些变化表达为命令。
哪些变化表达为事件。
哪些操作只是查询。
哪些能力通过 Endpoint 对外暴露。
哪些行为适合异步或周期性处理。
这一部分体现的 CleanDDD 实践重点主要包括:
先确定边界,再进入实现
命令、事件、查询各有各的位置
模型作为需求和实现之间的中间结构
规则尽量由对应模型负责
如果没有 modeling 这一层,需求很容易直接进入代码,系统后面会越来越像流程拼装。
有了这一步,后续工程结构和代码实现就有了清楚依据。
dotnet-init
cleanddd-dotnet-init 是可选步骤,用于新工程初始化。
如果准备从零开始创建一个新的 .NET / NetCorePal 工程,这一步就会使用。
如果工程已经存在,这一步可以跳过,直接进入 cleanddd-dotnet-coding。
这一部分处理的内容,重点不是普通意义上的“起项目”,而是根据前面的模型结果初始化工程骨架。通常会包括:
使用 NetCorePal Template 初始化项目
确定解决方案和工程结构
确定基础技术选项
为后续聚合、命令、事件、查询、Endpoint 等实现准备对应位置
这一部分体现的 CleanDDD 实践重点是:模型不只停留在描述里,还要继续进入工程结构。
NetCorePal 在这里承担的是承载角色。
前面的 requirements-analysis 和 modeling 更偏分析和设计,到了 dotnet-init,NetCorePal 开始把这些结果带到实际工程里。
如果是新项目,这一步很自然;如果是已有项目,就不需要额外做一次初始化。
dotnet-coding
cleanddd-dotnet-coding 进入的是实现阶段。
这一部分不是单纯“写代码”,而是根据前面的需求结果、模型结果以及现有工程结构,继续完成实际实现。通常会覆盖:
聚合实现
命令处理
查询处理
领域事件
API Endpoint
仓储
配置
测试
这一部分体现的 CleanDDD 实践重点,是让实现继续保持和需求、模型、工程结构的一致性。
也就是说,这里写的不是一段孤立代码,而是:
对应前面的需求整理结果
对应前面的模型结构
对应现有工程骨架
对应 NetCorePal 的实现方式
如果是已有工程,在 requirements-analysis 和 modeling 完成之后,可以直接进入 dotnet-coding。
如果是新工程,dotnet-coding 则接在 dotnet-init 后面继续往下实现。
如何使用
cleanddd-skills 的安装和使用说明,项目 README 里已经写得很清楚:
https://github.com/netcorepal/cleanddd-skills/blob/main/README.md
README 给出的使用步骤如下。
先克隆代码到本地:
git clone https://github.com/netcorepal/cleanddd-skills.git
cd cleanddd-skills
复制代码
然后运行安装脚本,将 skills 同步到当前用户的全局目录。
Windows PowerShell:
./scripts/install-skills.ps1
复制代码
macOS/Linux:
chmod +x scripts/install-skills.sh
./scripts/install-skills.sh
复制代码
安装完成之后,就可以和 Agent 对话,并按顺序使用这些 skills:
需求拆解:调用 cleanddd-requirements-analysis,生成结构化需求与事件流
领域建模:调用 cleanddd-modeling,基于上一步输出生成聚合、命令、查询、事件、Endpoint 设计
项目初始化:调用 cleanddd-dotnet-init,用模板创建项目骨架
代码实现:调用 cleanddd-dotnet-coding,基于模型生成代码骨架或具体实现
README 里还给了几句可以直接发给 Agent 的示例提示词:
“请先用 cleanddd-requirements-analysis 拆解 XXX 需求,给出表格化输出,然后用 cleanddd-modeling 生成模型设计。”
“使用 cleanddd-dotnet-init 创建一个包含 RabbitMQ 和 MySql 的 CleanDDD 项目。”
“基于上述模型,实现代码骨架。”
脚本会将仓库内 skills/ 目录下的技能逐个同步到目标目录,如果已有同名技能,会先删除后再复制,以保证版本一致。
cleanddd-skills 和 NetCorePal 的关系
两者分工很清楚。
cleanddd-skills 负责把实践过程整理成一条工作链路。
NetCorePal 负责把这条工作链路承载到 .NET 工程里。
可以简单理解成:
requirements-analysis 和 modeling 负责把业务和模型先整理出来
dotnet-init 和 dotnet-coding 负责把这些结果继续带进工程
NetCorePal 提供工程承载所需要的框架基础
如果只有框架,没有前面的实践链路,很容易变成“会用框架,但不会按 CleanDDD 组织工作”。
如果只有前面的分析和建模,没有 NetCorePal 这样的承载,结果又容易停在文档和讨论层面。
这两部分结合起来以后,需求、模型、工程骨架和实现之间就形成了清楚的衔接关系。
项目链接
cleanddd-skills 项目地址:
https://github.com/netcorepal/cleanddd-skills
更多内容,欢迎关注同名公众号: 老肖想当外语大佬
来源:程序园用户自行投稿发布,如果侵权,请联系站长删除
免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!
DDD
落地
就让
AI
干吧
相关帖子
AI元人文:在荆棘中开路——对四个实践性追问的回应
AI元人文:在荆棘中开路——对四个实践性追问的回应
AI元人文:在荆棘中开路——对四个实践性追问的回应
AI元人文:在荆棘中开路——对四个实践性追问的回应
AI元人文:在荆棘中开路——对四个实践性追问的回应
AI元人文:在荆棘中开路——对四个实践性追问的回应
AI元人文:在荆棘中开路——对四个实践性追问的回应
AI元人文:在荆棘中开路——对四个实践性追问的回应
AI 可以取代运维了吗?
测试人必备的4个AI Skills(附下载地址和详细用法)
回复
使用道具
举报
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
千斤顶
照妖镜
相关推荐
安全
AI元人文:在荆棘中开路——对四个实践性追问的回应
0
600
段一璇
2026-04-01
安全
AI元人文:在荆棘中开路——对四个实践性追问的回应
0
39
梢疠
2026-04-01
安全
AI元人文:在荆棘中开路——对四个实践性追问的回应
0
273
郜庄静
2026-04-01
安全
AI元人文:在荆棘中开路——对四个实践性追问的回应
0
831
叟减
2026-04-01
安全
AI元人文:在荆棘中开路——对四个实践性追问的回应
0
413
翁谌缜
2026-04-01
安全
AI元人文:在荆棘中开路——对四个实践性追问的回应
0
859
闵雇
2026-04-01
安全
AI元人文:在荆棘中开路——对四个实践性追问的回应
0
441
龙玮奇
2026-04-01
安全
AI元人文:在荆棘中开路——对四个实践性追问的回应
0
459
数察啜
2026-04-01
业界
AI 可以取代运维了吗?
0
933
愤血冒
2026-04-01
业界
测试人必备的4个AI Skills(附下载地址和详细用法)
0
83
遑盲
2026-04-01
高级模式
B
Color
Image
Link
Quote
Code
Smilies
您需要登录后才可以回帖
登录
|
立即注册
回复
本版积分规则
回帖并转播
回帖后跳转到最后一页
浏览过的版块
科技
安全
签约作者
程序园优秀签约作者
发帖
跑两獗
昨天 05:54
关注
0
粉丝关注
20
主题发布
板块介绍填写区域,请于后台编辑
财富榜{圆}
3934307807
991125
anyue1937
9994892
kk14977
6845359
4
xiangqian
638210
5
神泱
9539
6
宋子
9880
7
韶又彤
9911
8
注思
9034
9
荪俗
9023
10
诀锺
9036
查看更多
今日好文热榜
645
【ESP32】ESP32 使用 MQTT 连接华为云 IoT
770
Axios遭供应链投毒攻击(附排查与紧急补救
931
AI 可以取代运维了吗?
83
测试人必备的4个AI Skills(附下载地址和详
74
记一次Webshell流量分析2 | 添柴不加火
453
记一次Webshell流量分析2 | 添柴不加火
139
记一次Webshell流量分析2 | 添柴不加火
727
记一次Webshell流量分析2 | 添柴不加火
68
记一次Webshell流量分析2 | 添柴不加火
412
AI元人文:在荆棘中开路——对四个实践性追
930
记一次Webshell流量分析2 | 添柴不加火
3
Python模块与包管理完全指南:从入门到精通
422
记一次Webshell流量分析2 | 添柴不加火
2
Python模块与包管理完全指南:从入门到精通
271
AI元人文:在荆棘中开路——对四个实践性追
577
记一次Webshell流量分析2 | 添柴不加火
86
记一次Webshell流量分析2 | 添柴不加火
160
记一次Webshell流量分析2 | 添柴不加火
876
记一次Webshell流量分析2 | 添柴不加火
148
记一次Webshell流量分析2 | 添柴不加火