DDD/Clean Architecture跨子域相同Actor复用方案咨询

子域划分合理性确认 #

你当前将系统拆分为Stock、Users、Notifications三个子域的方案符合DDD规范：

• Stock属于核心域，承载库存管理的核心业务逻辑
• Users属于支撑域，负责用户身份、基础角色属性的维护
• Notifications属于通用域，负责通用消息触达能力
  三者边界清晰，不存在划分错误的问题。

核心认知修正 #

你认为不同子域的Actor是同一个对象，属于对限界上下文语义的误解：

• Users子域中的Manager/Employee是身份实体，仅负责维护「用户是否属于该角色、角色基础属性是什么」的核心逻辑
• Stock子域中的Manager/Employee是业务操作主体，负责维护「该角色在库存场景下可执行的操作范围」的业务规则
  两类对象所属上下文不同，承载的业务逻辑完全独立，本身就不该复用领域层代码。你认为「employee禁止创建产品的权限校验逻辑不该放在Users子域」的判断是完全正确的，Users子域不需要感知其他子域的业务规则，否则会破坏上下文边界，后续其他子域新增权限规则时都要修改Users子域代码，违反单一职责原则。

落地实现方案 #

按优先级推荐两种可行方案：

方案1：上下文映射+防腐层（生产环境首选） #

• Users子域仅对外暴露通用的角色查询接口，返回值仅包含用户ID、角色编码两个核心字段，不暴露内部领域对象
• Stock子域内部实现所有和库存业务相关的权限校验逻辑，仅依赖Users子域返回的角色编码做判断，所有和库存操作相关的权限规则全部收敛在Stock子域内部
  该方案完全符合DDD上下文边界要求，后续扩展灵活度最高。

方案2：共享内核（仅适用于小团队简单场景） #

如果当前团队规模小、业务迭代节奏慢、角色规则长期不会有大的调整，可以保留共享目录，但要严格控制共享内容的边界：

• 共享目录中仅存放无业务逻辑的通用常量、基础接口定义，比如角色枚举值、通用的角色ID字段定义
• 各子域的业务逻辑必须留在子域内部实现，绝对不能将业务逻辑放到共享目录中
  该方案是在开发效率和规范之间的折中，只要控制好共享内容的边界，不算违反DDD规范。

目录结构优化参考 #

|-- src
    |-- modules
        |-- users
            |-- app
              |-- user-facade.ts # 对外暴露的用户角色查询接口
            |-- domain
              |-- role.ts # 用户子域内部的角色领域对象，不对外暴露
            |-- infra
        |-- stock
            |-- app
              |-- stock-permission.ts # 库存场景权限校验逻辑，仅依赖用户子域返回的角色编码
            |-- domain
            |-- infra
        |-- notifications
            |-- app
            |-- domain
            |-- infra
        |-- shared
            |-- domain
              |-- role-const.ts # 仅存放角色枚举等无业务逻辑的常量

用例图调整建议 #

不需要在多个子域中重复定义Actor，可将Actor定义为全局公共主体，不同子域的用例分别关联对应的Actor即可，不同子域的用例本身就代表了不同上下文下的操作规则，不会产生冲突。

内容的提问来源于stack exchange，提问作者Dyarlen Iber