不能。eslint仅分析ast，不理解ddd语义，需将aggregate、domainevent等约束转化为基于路径、命名、导入关系和类结构的可检测代码模式。

ESLint 能否直接检测 DDD 概念？

不能。ESLint 本身只分析 AST，不理解 Aggregate、DomainEvent、Repository 这类业务语义。它只能识别语法结构（如类声明、函数调用、导入路径），无法判断一个类是否“应该”是值对象还是实体——这需要你把 DDD 约束翻译成可检测的代码模式。

如何把 DDD 规则转成 ESLint 可执行的规则

核心思路是：用文件路径 + 命名约定 + 导入关系 + 类声明结构，组合出可验证的契约。例如：

• src/domain/user/ 下的 *.ts 文件，若导出类名以 Aggregate 结尾，必须继承自 BaseAggregate（通过 ClassDeclaration.superClass AST 节点校验）
• src/domain/**/events/ 下的文件，导出的类必须实现 DomainEvent 接口（检查 implements 子句或类型断言）
• src/infrastructure/persistence/ 中的文件，禁止直接 import src/application/ 或 src/domain/（用 ImportDeclaration + source.value 正则匹配拦截）
• src/domain/**/value-objects/ 中的类，必须是 export class 且不含 private 构造函数以外的任何方法（遍历 ClassBody.body，过滤掉 Constructor 和 MethodDefinition）

实际落地要绕开哪些坑

很多团队卡在第一步：写了个规则但没生效。常见原因包括：

WorkRally

WorkRally是一款由腾讯视频推出的AI漫剧智能创作平台。

下载

• 插件未在 .eslintrc.js 的 plugins 数组里注册，或未在 rules 中显式启用（如 "my-ddd/no-domain-import-in-infrastructure": "error"）
• 规则依赖路径解析，但项目用了 tsconfig.json 的 paths 别名，ESLint 默认不处理——得配 eslint-import-resolver-typescript 并在 settings 里指定 project
• 自定义规则里用 context.getSourceCode().getText() 做字符串匹配，结果被 TypeScript 编译前的装饰器、泛型等干扰；应优先用 AST 节点类型和属性判断（如 node.type === 'ClassDeclaration'）
• VSCode ESLint 插件默认只校验打开的文件，而 DDD 层间越界常发生在未打开的 infrastructure 文件里——需确保 eslint.workingDirectories 包含整个 src/，且 eslint.run 设为 "onSave" 或 "onType"

为什么建议从 “层间依赖” 和 “命名空间约束” 入手

DDD 最容易违反、也最易自动化的就是这两类。比起强行校验“这个类是否符合聚合根生命周期”，不如先守住底线：

• 禁止 domain → infrastructure 的反向 import（用 no-restricted-imports 配置路径白名单）
• 强制 application/use-cases 只能 import domain 和 shared（同上）
• 所有 src/domain/**/entities/ 下的类名必须含 Entity 后缀（用 no-invalid-filename 自定义规则）

这些规则上线后，开发者立刻能感知到约束，后续再逐步叠加更细粒度的领域语义校验。别一上来就写 validate-aggregate-invariants——AST 里根本找不到“不变量”的节点。