为验证业务规则的 POJO 编写不变量

【问题标题】：Writing Invariants For POJOs That Validate Business Rules为验证业务规则的 POJO 编写不变量
【发布时间】：2020-04-01 15:06:11
【问题描述】：

我想开始为我的课程结合编写不变量的做法。对于我的 POJO，通过根据业务规则验证其状态来验证其状态是否是一种好习惯。说我有比如这个类：

@Data
public class Pick {
    List<Substitution> substitutions = new ArrayList<>();
}

现在，我的不变量表示列表中的每个替换对象都需要有替换原因。在作为简单数据载体的 POJO 中进行此类业务检查是否是一种好习惯？

请注意，我已经使用了@NonNull，它也是一个不变量，虽然是一个非常基本的变量。编写不变量来测试复杂的业务关系 b/w 您的字段是否是一种好习惯？

【问题讨论】：

标签： java oop

【解决方案1】：

JSR 380 是用于 bean 验证的 Java API 规范，是 Jakarta EE 和 JavaSE 的一部分，它使用 @NotNull、@Min 和 @Max 等注释确保 bean 的属性满足特定标准。

我们可以看到这种方法在 Java 生态系统中被大量使用，只要它不涉及您的业务逻辑和数据对象并保持它们的清洁，它就是愚蠢的

更多here

【讨论】：

你能解释一下“......只要它不触及你的业务逻辑......”是什么意思。我的 POJO 确实使用某些业务规则来验证其状态。就像我在问题中提到的那样，每个替换都应该有一个原因，并且应该来自给定的枚举。这显然是一种商业验证。
我无法回答这么多数据，在某些时候您的业务验证转向业务逻辑，但主要是如果您使用您的选择，则有 2 种“规则”：编译和运行时间，所以如果 f.e 如果没有替代验证，你会返回错误，但如果你会为 0、1、2 做一些不同的事情，这可能是业务逻辑。如果是第一个，让他们远离。