是否应将领域对象LicensePlate的构造限制到外部服务？

假设我有一个值对象LicensePlate，它是领域实体Car的一部分。但生成车牌的逻辑不属于我的领域，我只能通过领域服务RegistrationAgency.obtainPlate(Car car)获取车牌，该服务在基础设施层由DMV.obtainPlate(Car car)实现，会调用外部API。我认为应该限制LicensePlate的构造，确保所有LicensePlate实例都是合法的（即由注册机构生成），这个顾虑合理吗？我想到的解决方案是把LicensePlate的构造函数设为私有，并添加静态工厂方法LicensePlate.build(car, licenseNumberFactory)，由LicenseNumberFactory负责调用外部API。这个方案是否繁琐？是否符合DDD原则？还是直接把LicensePlate设为公有来避免这些问题？

你的顾虑完全合理 #

这是DDD中值对象不变性与约束性的核心体现：值对象的实例必须始终处于合法状态，而在你的业务语境里，“车牌必须由官方注册机构生成”是明确的领域规则。如果开放公有构造，任何代码都能随意创建不符合规则的车牌（比如格式错误、未通过官方流程生成的），直接破坏领域模型的一致性，后续会引发大量数据合法性问题。

你的解决方案符合DDD原则，并不繁琐 #

将LicensePlate的构造设为私有，通过静态工厂方法封装创建逻辑，是DDD中保护值对象完整性的标准实践：

• 私有构造从根本上杜绝了外部绕过约束直接创建实例的可能；
• 静态工厂方法LicensePlate.build(car, licenseNumberFactory)明确了创建车牌的必要依赖（车辆信息、官方号码生成器），同时将外部API调用的细节委托给LicenseNumberFactory，实现了关注点分离——LicensePlate只负责维护自身的格式合法性，外部依赖的API调用则交给基础设施层的实现；
• 领域服务RegistrationAgency可以依赖这个工厂方法，而基础设施层的DMV实现提供具体的LicenseNumberFactory，完美契合DDD中领域层与基础设施层解耦的要求。

如果觉得当前方案略有冗余，可以做简化：将LicensePlate的构造设为包级私有，让同包的RegistrationAgency直接调用构造函数，但静态工厂方法的方式扩展性更强——比如后续支持不同地区的注册机构，只需替换LicenseNumberFactory的实现即可。

直接设为公有构造不可取 #

开放公有构造等于放弃了对领域规则的代码级强制执行，会导致领域模型退化：

• 任何模块都能创建无效车牌，数据合法性只能依赖运行时校验或文档约束，维护成本和出错风险大幅提升；
• 领域规则无法通过模型本身体现，违背了DDD“代码即文档”的设计理念。

内容的提问来源于stack exchange，提问作者Douglas Monteiro