DDD领域实体验证：如何强制业务规则不被绕过？

问题1：创建实体依赖外部服务校验时，将领域服务传入实体创建方法是否合理？ #

这种做法不太推荐，核心问题是会破坏实体的内聚性与纯度。实体的职责本应是封装自身状态与核心业务规则，依赖外部服务会让它耦合到外部逻辑，不仅难以单独测试，还违背了DDD中实体“自我管理状态”的设计原则。

更合理的处理方式：

• 把创建逻辑封装到领域服务或实体工厂中，由这些组件调用外部校验服务（比如查询数据库、调用其他领域服务），确认校验通过后再创建并返回合法实体。
• 如果必须在创建阶段强制校验，可把校验逻辑抽象成独立接口（比如ProductCreationValidator），由工厂/服务注入后执行，实体本身不需要感知外部服务的存在。

问题2：实体创建与领域服务分离，存在跳过校验的风险，这是通用实践吗？如何规避？ #

这种分离是DDD中的常见做法，但跳过校验的风险确实存在。不过完全可以通过代码层面的强制机制规避，而非仅依赖代码审查：

• 把实体的构造函数设为包私有或受保护，禁止外部代码直接new实体。只允许领域服务或工厂方法创建实体，确保所有创建流程都必须经过校验环节。
• 仓储层只接受通过合法流程创建的实体，拒绝直接传入未经校验的对象（核心还是从创建入口限制，仓储检查仅作为补充）。

代码审查可作为辅助手段，但强制的访问控制才是最可靠的保障，这也是业界通用实践。

问题3：设置实体属性时存在绕过校验的可能，是否要把领域服务传入工厂方法？ #

绝对不建议这么做，会让工厂方法或实体变得“不纯”（依赖外部状态、带有副作用），后续测试和维护都会变得麻烦。更优的解决方案有这几种：

1. 封装成领域服务操作：把设置isPublished的逻辑放到领域服务中，比如写一个publishTemplate(Template template)方法，在服务里完成所有前置校验（比如检查关联资源是否齐全、是否符合发布规则），校验通过后再调用实体的内部方法修改状态。
2. 实体内部封装状态变更：给实体的isPublished设置私有 setter，只暴露publish()这类业务方法。如果校验不需要外部服务，可把简单校验放在这个方法里；如果需要外部服务，还是交给领域服务触发校验，再调用实体的publish()方法。
3. 利用领域事件：当触发发布操作时，抛出TemplatePublishRequested事件，由领域服务监听事件并完成校验，校验通过后再更新实体的发布状态。这种方式能进一步解耦校验逻辑和实体状态变更。

内容的提问来源于stack exchange，提问作者Mr X