您如何处理领域驱动设计中复杂聚合的验证？您是否正在整合您的业务规则/验证逻辑？
我了解参数验证，也了解可以附加到模型本身的属性验证，并执行诸如检查电子邮件地址或邮政编码是否有效或名字是否具有最小和最大长度之类的操作。
但是涉及多个模型的复杂验证又如何呢？您通常将这些规则和方法放置在架构中的什么位置？您使用什么模式(如果有)来实现它们？
最佳答案
不要在整个应用程序中依赖 IsValid(xx) 调用，而是考虑采纳 Greg Young 的一些建议:
Don't ever let your entities get into an invalid state.
这基本上意味着您不再将实体视为纯粹的数据容器，而更多地关注具有行为的对象。
考虑一个人的地址示例:
person.Address = "123 my street";
person.City = "Houston";
person.State = "TX";
person.Zip = 12345;
在任何这些调用之间，您的实体都是无效的(因为您将拥有彼此不一致的属性。现在考虑一下:
person.ChangeAddress(.......);
所有与更改地址行为相关的调用现在都是一个原子单元。您的实体在这里永远不会无效。
如果您采用这种建模行为而不是状态的想法，那么您可以达到一个不允许无效实体的模型。
有关此问题的详细讨论，请查看此 infoq 采访:http://www.infoq.com/interviews/greg-young-ddd
关于领域驱动设计中的验证，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/516615/