验证规则和业务规则有什么区别？
根据我的理解，'如果业务对象/对象的状态不符合预期，则抛出错误消息'是一个验证规则，并且'当业务对象/对象的状态是或不相等时到某事，然后改变一些业务对象/对象的状态[或采取一些行动/事件，但不只是抛出一个错误]'是一个业务规则。
验证可以是 UI 验证 - 验证 UI 字段的值或应用程序验证 - 验证业务对象状态。
我不确定我上面的理解是否正确。在我的项目中，我们有一个验证框架，其中一个简单的验证调用需要业务对象来验证某些东西和一个收集所有错误的错误收集器。错误随后显示在屏幕上。
除此之外，我们还有属于上述第二类的规则，即检查业务对象/对象状态并采取一些措施，例如更改另一个业务对象的状态。我正在尝试找出使用某些框架 [不是验证框架] 或规则引擎来实施此类规则的策略。
能否请您帮助我理解上述两种规则之间的区别，如果有任何实施策略/建议，会有所帮助。
【问题讨论】：
标签： terminology business-logic
验证是检查输入的值对于其字段的上下文是否合法（从技术角度来看），例如：5 作为 Age(v.s. -5) 可以接受的数值吗？而 -5 是可以接受的例如温度。
业务规则更多的是业务视角。检查值（通过验证）是否可以被业务的政策和程序接受。例如。被允许注册的人必须是居民，并且年满 18 岁或以上..等等。业务规则可能会检查一个（或多个）字段值，并且可能会查阅存储在数据库中的数据和/或进行一些计算以确保值通过业务规则。
因此，对于上面hanna 发布的示例，值 15 应该通过字段验证（因为它是 Age 的有效值），但它不会通过已婚人员年龄必须大于 15 的业务规则检查.
【讨论】：
简而言之；验证规则确定基本有效性； “这是一个有效的电子邮件地址吗？”业务规则确定如何处理有效数据； “我可以将用户的确认电子邮件设置为提交的值吗？”业务规则可以迁移到验证逻辑中；但通常，验证不是由业务规则引擎完成的。
【讨论】：
验证通常是指不需要查询数据库来验证它们的规则。例如最小密码长度。 业务规则通常需要数据库查询进行验证。例如，您提款的金额不能超过您的账户余额。这是一个商业规则。 因此，例如，在申请中硬编码的学校注册可接受的最低年龄是一个验证规则。
【讨论】：
一个业务规则，从名字上看，是从业务角度做的数据检查，比如婚姻状况不能“结婚”，年龄小于15岁，基本上是业务变化的规则做生意。
验证，通常与用户界面有关，可以在商务以外的地方常见，可以通过常识推导出来，例如，电子邮件格式应该有特定的形式，或者是否有开始日期和结束日期，插入的结束日期应大于插入开始日期的日期。
【讨论】：
这一切都取决于视角。验证规则和业务规则实际上是一回事。我们有时会在逻辑上对规则的复杂程度进行分类，最基本的是验证，然后更复杂的是业务规则。这是不正确的，因为这取决于！ “复杂性规则层次结构”示例：-
通常从字符串转换为强类型，示例
现在我们有了一个强类型，检查边界，变得更加模糊
现在完全模棱两可......这取决于！
您是否注意到经理必须最少制作 200 个字符的 Notes，而其他人则必须从零到最多 100 个。 因此，有些人可能会争辩说最大字符数是验证，但显然业务需要经理做更多的事情。那么它是什么？
也许将一切都称为业务规则，因为验证的最终目标是确保“所有业务上下文中的数据正确性”。
【讨论】：