戏说领域驱动设计(十八)——内验

本文介绍了领域驱动设计中的内验概念,强调了验证的重要性,并通过Python微信订餐小程序和量化交易系统的实例,讲解了验证服务基类和验证触发的时机。文章指出,应确保对象在创建后始终保持合法状态,不依赖前端或数据库约束,而是通过验证来保障。内验发生在对象构造完成后,而对象在创建后的操作和持久化阶段不需要二次验证,因为合法性已在构造时得到保证。此外,文章提倡通过聚合根控制聚合内部对象的修改,以维护对象的不变性。
摘要由CSDN通过智能技术生成

Python微信订餐小程序课程视频

https://edu.csdn.net/course/detail/36074

Python实战量化交易理财系统

https://edu.csdn.net/course/detail/35475
  验证在我们现实的生活中非常常见,比如您找工作得先整个面试验证你的能力是否靠谱;找对象得先验证下对方的颜值和升值空间。有些工程师写代码从不验证,我觉得是有三个原因,一是意识不够,过于相信前端或外部服务;二是个人缺少主动思考的能力;三是团队负责人的问题,您都当了领导了为什么不制定一些基本开发规则给团队树规矩。实际上,验证这个事情说简单也的确不难,不就是个值判断吗?可如果想把这个事情做好还真是一个需要值得思考的工作,就和异常的处理一样,我告诉你就算干了10年的开发都未必知道怎么有效的使用异常。代码里中充满了土味,一看就特Low。所以我们把验证这个事情单独的提出来,越是越是简单的东西想写好才越难。

您应该不知道“对象不变性”这个名字吧?领域模型包括实体与值对象都需要遵循这个规则,就是说不论你对一个领域对像做什么操作,不论怎么盘它,其本质应该保持不变。不都说“江没易改,本性难变”吗?上述的操作不仅是调用对象上的方法,还包括构造对象的过程。有一个例子说“一个没有角的独角兽还能称得上是独角兽吗?”,简单来说就是你需要始终保持领域对象处于合法的状态或者说是属性的值不能超出业务规则限制。比如订单对象:客户信息不能为空、价格信息不能为负数等、订单项数量要大于0小于100等,不论你在订单对象上做什么操作,这些属性值都不可以超出约束。

想要保证对象的“不变性”,不能依赖于前端的输入和数据库本身的约束,那些基本都不靠谱,最好的方式还是首推“验证”。针对对象本身是否合法的验证我称之为“内验”。相对的,验证某个业务先决条件的验证称之为“外验”,因为此时的验证已经超出了对象本身的规则范围。既然需要对所有的对象都进行验证,就应该将其做为一种通用的能力放到OOP编程框架中。其实我个人特别不喜欢称之为“框架”,感觉概念太大了,所以我们就称呼为基础类库吧。这个类库可以提供一些用于检验领域对象是否合法的工具随用随取,不用重复的造轮子。

领域对象内验的实现思想很简单:为每个领域对象中加入用于验证的方法和验证规则,在对象创建后或持久化前通过调用每个对象的验证方法实现验证逻辑。您一定要注意前面这句话中所说的触发验证方法的时机,别回头不管什么场景就调用验证,这叫过度设计,那代码会让人吐的。另外,既然是通用的能力而且用于验证领域对象,就最好将其放到领域模型的基类中按需在具体类中进行重写,所以就让我们从这些基类作为起点开搞。

一、验证服务基类

看过前面的文章您应该已经知道了我们在实现验证的时候使用了一种类“规约模式”,也就是将验证规则嵌入到领域对象中,并在合适的时机进行验证方法的调用。为此,在设计领域模型基类的时候我们让其继承的了一个用于验证的父类“ValidatableBase”,这个类里面包含了两个方法,具体代码如下所示。“ValidatableBase”是一个抽象类,实现了接口“Validatable”,这个接口很重要,但凡需要验证的对象都会实现这个接口。 您可以看一下下面的类图,说得挺绕其实就三个组件。

public interface Validatable {

 /**
 * 验证
 * @return 验证结果
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值