DDD 这些年一直有点尴尬。知道它有价值的人不少真正愿意照着它的方式把需求、模型、结构和代码一步一步做下来的人并不多。最常见的印象也差不多概念多、步骤多、层次多看起来像是把原本能直接写出来的业务系统又绕了一圈。这个判断里有误解也有现实原因。误解在于很多时候被嫌“繁琐”的部分恰恰是业务系统要做稳、做久、做清楚本来就需要的动作。现实原因在于如果手里没有合适的框架和方法这些动作确实很难坚持最后就会变成理念知道一点工程做成另外一套。工具层面NetCorePal 解决了框架和工程承载的问题。具体到实操层面现在有了 AI这件事开始变得简单起来。我们把 CleanDDD 实践里需要遵守和执行的核心原则整理成 skills让 AI Agent 能沿着固定顺序参与需求分析、领域建模、项目初始化和代码实现。由于 CleanDDD 本身的原则和方法都非常明确、可执行AI Agent 参与进来会比较自然整个过程也更容易组织起来。于是就有了cleanddd-skills。cleanddd-skills 包含哪些内容cleanddd-skills主体由四个部分组成cleanddd-requirements-analysiscleanddd-modelingcleanddd-dotnet-initcleanddd-dotnet-coding这四个部分分别处理四类事情requirements-analysis负责把需求整理成结构化描述。modeling负责把结构化需求描述转换成系统模型结构。dotnet-init负责在需要时根据模型结果初始化新的工程骨架。dotnet-coding负责在需求、模型和工程结构已经明确的基础上继续完成实现。如果是新工程通常会按完整链路使用requirements-analysis - modeling - dotnet-init - dotnet-coding如果已经有工程可以直接使用requirements-analysis - modeling - dotnet-codingcleanddd-skills的重点不在于把四个 skill 摆在那里而在于把实践 CleanDDD 的过程组织成一条前后连续的流程。requirements-analysiscleanddd-requirements-analysis只处理需求本身不进入建模也不进入代码。这一部分的任务是把原始需求整理成后面能继续使用的结构化描述。通常会涉及这些内容干系人是谁业务对象有哪些每条需求归属于哪个对象哪些是动作哪些是状态哪些是约束哪些触发会引出后续行为哪些依赖关系是显性的哪些关系藏在描述背后这一部分体现的 CleanDDD 实践重点很明确先用业务语言把问题说明白再进入模型语言。如果需求阶段还是散乱的自然语言后面的建模就很容易依赖临时理解。而 requirements-analysis 做的就是把这些输入先整理成适合建模的形式。这一部分的产出不是为了写一份好看的文档而是为了给 modeling 提供明确输入。modelingcleanddd-modeling接在 requirements-analysis 后面负责把结构化需求描述继续转换成系统模型结构。这一部分通常会整理出聚合命令事件查询API Endpoint定时任务这一部分的工作重点不是解释术语而是确定结构和归属。哪些行为进入哪个聚合。哪些变化表达为命令。哪些变化表达为事件。哪些操作只是查询。哪些能力通过 Endpoint 对外暴露。哪些行为适合异步或周期性处理。这一部分体现的 CleanDDD 实践重点主要包括先确定边界再进入实现命令、事件、查询各有各的位置模型作为需求和实现之间的中间结构规则尽量由对应模型负责如果没有 modeling 这一层需求很容易直接进入代码系统后面会越来越像流程拼装。有了这一步后续工程结构和代码实现就有了清楚依据。dotnet-initcleanddd-dotnet-init是可选步骤用于新工程初始化。如果准备从零开始创建一个新的 .NET / NetCorePal 工程这一步就会使用。如果工程已经存在这一步可以跳过直接进入cleanddd-dotnet-coding。这一部分处理的内容重点不是普通意义上的“起项目”而是根据前面的模型结果初始化工程骨架。通常会包括使用 NetCorePal Template 初始化项目确定解决方案和工程结构确定基础技术选项为后续聚合、命令、事件、查询、Endpoint 等实现准备对应位置这一部分体现的 CleanDDD 实践重点是模型不只停留在描述里还要继续进入工程结构。NetCorePal 在这里承担的是承载角色。前面的 requirements-analysis 和 modeling 更偏分析和设计到了 dotnet-initNetCorePal 开始把这些结果带到实际工程里。如果是新项目这一步很自然如果是已有项目就不需要额外做一次初始化。dotnet-codingcleanddd-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.mdREADME 给出的使用步骤如下。先克隆代码到本地git clone https://github.com/netcorepal/cleanddd-skills.git cd cleanddd-skills然后运行安装脚本将 skills 同步到当前用户的全局目录。Windows PowerShell./scripts/install-skills.ps1macOS/Linuxchmod 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 这样的承载结果又容易停在文档和讨论层面。这两部分结合起来以后需求、模型、工程骨架和实现之间就形成了清楚的衔接关系。文章转载自老肖想当外语大佬原文链接https://www.cnblogs.com/xiaoweiyu/p/19795560体验地址http://www.jnpfsoft.com/?from57