从壹开始微服务 [ DDD ] 之九 ║从军事故事中,明白领域命令验证(上)

烽烟

哈喽大家周二好呀,咱们又见面了,上周末掐指一算,距离 圣诞节 只有 5 周的时间了(如果你还不知道为啥我要提圣诞节这个时间点,可以看看我的第二系列开篇《之一 ║ D3模式设计初探 与 我的计划书》),然后我简单的思考了下这个DDD领域驱动设计还剩下的知识点,现在已经进入了第二部分,就是领域命令和领域驱动这一块,第三部分包括Identity验证和.net core api等设计点,大概就是剩了这么多,预计应该能在圣诞节前完成。还有一个就是,之前的八篇文章,已经比较完整的实现了普通框架的整体搭建,我也单独的新建了一个 Git分支—— Framework8 ,如果你不想用领域命令、领域事件、事件回溯这些东西,仅仅就想要一个空的框架,一个包括 EFCore+Dtos+Automapper+IoC+Repository 的空框架(就比如我的第一个系列,就是一个普通的框架,请不要再说是这是一个普通三层了,拜托😂),你就可以直接用这个Framework8 分支即可。

 

言归正传,上次咱们说到了创建新student的时候,提出来一个问题,不知道大家是否还记得,这里再给大家说明一下,还是每篇一问,希望能好好思考下,或者是看看自己是如何设计的:

问题1:平时是如何进行表单验证的(包括:判空、字符类型有效、业务验证:成人不能小于18岁、金额不能小于0等)?

问题2:如果后来验证变化了改怎么办?(比如:手机号要支持全球,或者座机;亦或者退休年龄从60岁变成65岁;)

1、JavaScript前端验证即可,后端从来不进行验证?(问题2:修改js)

2、后端验证:直接在Controller中,通过写很多判断逻辑,比如 If Else等,而且CURD还需要写很多重复的判断方法?(问题2:每一个地方都需要仔细修改,额。)

3、后端验证:写一个统一的验证类,或者验证机制,比如一个公共类?甚至更高级的AOP切面验证?(问题2:好像还是无法满足每个领域特例)

4、后端验证:在DTO基础上,基于领域命令,通过中介者Bus分发?(当然这个就是以后我要写的)

 

其实说实话,前三种我都用过,甚至现在偶尔也还是会用,毕竟很平常的用法,但是现在我感觉第四种真的很整洁,真正的把整体项目放到了领域中,一切以领域为核心了 。这里我先把第四种的应用层 Service 方法简单写下,你就知道多么简洁了,具体的会在下面两篇文章中说到:

 /// <summary>
 /// StudentAppService 添加新 Student 
 /// </summary>
 public void Register(StudentViewModel studentViewModel)
 {
     //讲视图模型,转换成命名模型
     var registerCommand = _mapper.Map<RegisterStudentCommand>(studentViewModel);
     //通过Mediator处理程序分发命令
     //执行顺序:验证 -> 通知 -> 注册

     Bus.SendCommand(registerCommand);
 }

 

老张说:这两天我在研究,啃书的时候,发现了这个DDD领域驱动的整体流程,从前台数据传递视图模型 ,到Dto的命令模型,然后对其校验的命令验证模式,最后还有总线分发,然后就是异常通知等等,就像是一场军事战斗中的过程:

这里说的命令是动作的意思,是用户发出的一个请求(从前台向后端),当然你也可以理解是改领域模型下的命令动作(从内到外),还记得我们说到的读写分离CQRS么,就是Command。

每一个个小的战役(领域模型),都会有自己战场的一些信息和动作数据(视图模型),当然这里有正常的消息,也有恶性攻击或者不当的操作,每一个动作执行都是一个前锋部队(领域命令模型),先锋部队把这些数据打包,加上时间戳等标识,生成命令标签,这个时候通过总线指挥官(中介者),交给参谋来处理数据命令(领域验证),进行安全甄别,将正常的、正确的往下传递,传给司令部(持久化),如果是恶性的错误信息,则通过通讯兵打包给前线(通知),每次前线执行操作,只需要看看是否有通讯兵是否有错误异常提醒,如果没有则证明执行成功。

当然还有事件回溯和事件源,我会在以后文章说明,不知道这个栗子是否合理,如果大家看不懂也没关系,或者请下边留言,我们一起讨论讨论。

 

零、今天实现棕色的部分

 

 

一、领域命令Commands —— 领域模型的先锋官

 说到这个领域命令,大家肯定不会陌生,或者说应该是在哪里见过,没错!就是我们在上上一篇《七 ║项目第一次实现 & CQRS初探》中,说到的读写分离 CQRS 中的C —— Commend命令,这里我简单说下,为什么叫先锋官,我们把整个项目比作一个战场的化,前端一直和后端进行交互 —— 表单提交,这个时候,肯定就离不开查询和命令,查询这里暂时先不说,就说一下这个命令,前端的任何一个动作其实都是一个事件。

大家肯定知道从前台DTO拿到的实体模型数据,肯定不能直接操作领域模型(当然现在我们是直接这么操作的,直接用的是视图模型和领域模型进行交互操作,这个时候领域模型就起到了一个冲锋陷阵的作用了,其实这种设计不符合DDD领域设计的思想,因为领域模型是一切的核心,它应该是一个个司令部,不能参与到前线,他会下发出一个个的命令模型去执行),这个时候我们的命令模型就出现了,他充当着从前台到后台的先锋官的作用,执行一个个的命令指令,完成从视图模型到领域模型的操作和数据的过度作用。

然后再通过中介者模式,通过事件总线,通过领域命令一一分发出去,然后通过验证,最后是实现(比如持久化等),然后将中间产生的错误信息,或者通知信息,再扔给了前台,所以说,领域命令就是一个先锋官,这里你也看到了,他是一个个先锋官,他的作用是起到引导的作用,是下达命令的作用,他是不负责具体的逻辑实现的,具体是为什么呢,先按下不表。咱们先看看如何定义一个领域命令。

希望上边的三段话大家可以帮忙想一想,如果想通了,但是和我写的不一样,请一定要留言!

 

1、创建命令抽象基类

 在 Christ3D.Domain.Core 领域核心层中,新建Commands文件夹,并该文件夹下创建抽象命令基类 Command,这里可能有小伙伴会问,这个层的作用,我就简单再说下,这个层的作用是为了定义核心的领域知识的,说人话就是很多基类,比如 Entity 是领域模型的基类,ValueObject 是值对象的基类,这里的Command 是领域命令的基类,当然,你也可以把他放到领域层中,用一个 Base 文件夹来表示,这小问题就不要争议了。

namespace Christ3D.Domain.Core.Commands
{
    /// <summary>
    /// 抽象命令基类
    /// </summary>
    public abstract class Command 
    {
        //时间戳
        public DateTime Timestamp { get; private set; }
        //验证结果,需要引用FluentValidation
        public ValidationResult ValidationResult { get; set; }

        protected Command()
        {
            Timestamp = DateTime.Now;
        }

        //定义抽象方法,是否有效
        public abstract bool IsValid();
    }
}

思考:为什么要单单顶一个抽象方法 IsValid();

 

2、定义 StudentCommand ,领域命令模型

 上边的领域基类建好以后,我们就需要给每一个领域模型,建立领域命令了,这里有一个小小的绕,你这个时候需要静一静,想一想,

 1、为什么每一个领域模型都需要一个命令模型。

 2、为什么是一个抽象类。

namespace Christ3D.Domain.Commands
{
    /// <summary>
    /// 定义一个抽象的 Student 命令模型
    /// 继承 Command
    /// 这个模型主要作用就是用来创建命令动作的,不是用来实例化存数据的,所以是一个抽象类
    /// </summary>
    public abstract class StudentCommand : Command
    {
        public Guid Id { get; protected set; }//注意:set 都是 protected 的 public string Name { get; protected set; }

        public string Email { get; protected set; }

        public DateTime BirthDate { get; protected set; }

        public string Phone { get; protected set; }
    }
}

希望这个时候你已经明白了上边的两个问题了,如果不是很明白,请再好好思考下,如果已经明白了,请继续往下走。

 

3、基于命令模型,创建各种动作指令

 上边的模型创造出来了,咱们需要用它来实现各种动作命令了,比如 URD 操作,肯定是没有 C 查询的。这里就重点说一下创建吧,剩下两个都一样。

namespace Christ3D.Domain.Commands
{
    /// <summary>
    /// 注册一个添加 Student 命令
    /// 基础抽象学生命令模型
    /// </summary>
    public class RegisterStudentCommand : StudentCommand
    {
        // set 受保护,只能通过构造函数方法赋值
        public RegisterStudentCommand(string name, string email, DateTime birthDate, string phone)
        {
            Name = name;
            Email = email;
            BirthDate = birthDate;
            Phone = phone;
        }

        // 重写基类中的 是否有效 方法
        // 主要是为了引入命令验证 RegisterStudentCommandValidation。
        public override bool IsValid()
        {
            ValidationResult = new RegisterStudentCommandValidation().Validate(this);//注意:这个就是命令验证,我们会在下边实现它 return ValidationResult.IsValid;
        }
    }
}

这里你应该就能明白第一步的那个问题了吧:为什么要单单顶一个抽象方法 IsValid();

不仅仅是验证当前命令模型是否有效(无效是指:数据有错误、验证失败等等),只有有效了才可以往下继续走(比如持久化等 ),还要获取验证失败的情况下,收录哪些错误信息,并返回到前台,这个就是

new RegisterStudentCommandValidation()

的作用。注意这里还没有实现,我们接下来就会实现它。

添加学生命令写完了,然后就是更新 UpdateStudentCommand 和 删除 RemoveStudentCommand 了,这里就不多说了。

 

 

二、领域验证Validations —— 领域模型的安保官

 这里为啥要说是安保官(就是起的名字,要是不贴切可以留言)呢,因为这是从前台 视图模型 到 领域模型 的一个屏障,这个就不用解释了,因为他就是一个验证的作用,当一个个命令执行的时候,需要对数据进行处理,就好像前线先锋部队执行一个个命令的时候,需要对一个个事件或者数据进行判断,有些错误的,假的数据是不能传达到领域模型中的,而我们的先锋官是不会处理这些的,他们只负责一个个命令的执行,验证工作就交给了Validations,而且是每一条命令都需要进行验证,这是肯定的。那如何创建基于命令的验证Validations呢,请往下看。

1、基于StudentCommand 创建抽象验证基类

在上边的领域命令中,我们定义一个公共的抽象命令基类,在验证中,FluentValidation已经为我们定义好了一个抽象基类 AbstractValidator,所以我们只需要继承它就行。

namespace Christ3D.Domain.Validations
{
    /// <summary>
    /// 定义基于 StudentCommand 的抽象基类 StudentValidation
    /// 继承 抽象类 AbstractValidator
    /// 注意需要引用 FluentValidation
    /// 注意这里的 T 是命令模型
    /// </summary>
    /// <typeparam name="T">泛型类</typeparam>
    public abstract class StudentValidation<T> : AbstractValidator<T> where T : StudentCommand
    {
        //受保护方法,验证Name
        protected void ValidateName()
        {
       //定义规则,c 就是当前 StudentCommand 类 RuleFor(c
=> c.Name) .NotEmpty().WithMessage("姓名不能为空")//判断不能为空,如果为空则显示Message .Length(2, 10).WithMessage("姓名在2~10个字符之间");//定义 Name 的长度 } //验证年龄 protected void ValidateBirthDate() { RuleFor(c => c.BirthDate) .NotEmpty() .Must(HaveMinimumAge)//Must 表示必须满足某一个条件,参数是一个bool类型的方法,更像是一个委托事件 .WithMessage("学生应该14岁以上!"); } //验证邮箱 protected void ValidateEmail() { RuleFor(c => c.Email) .NotEmpty() .EmailAddress(); } //验证手机号 protected void ValidatePhone() { RuleFor(c => c.Phone) .NotEmpty() .Must(HavePhone) .WithMessage("手机号应该为11位!"); } //验证Guid protected void ValidateId() { RuleFor(c => c.Id) .NotEqual(Guid.Empty); } // 表达式 protected static bool HaveMinimumAge(DateTime birthDate) { return birthDate <= DateTime.Now.AddYears(-14); } // 表达式 protected static bool HavePhone(string phone) { return phone.Length == 11; } } }

 关于 FluentValidation 的使用,这里就不多说了,大家可以自己使用,基本的也就是这么多了,当然大家也可以自己写一些复杂的运算,这里要说的重点是,大家应该也已经发现了,每一个验证方法都是独立的,互不影响,就算是有一个出现错误(当然不是编译错误),也不会影响当前整个领域命令,也就等同于不影响当前事件操作,是不是和以前相比,不仅方便而且安全性更高了。

这个时候我们定义了这个抽象的学生验证基类,剩下的就是需要针对不同的,每一个领域命令,设计领域验证了。

 

2、实现各个领域命令模型的验证操作

这里就简单说一个添加学生的命令验证,我们实现 StudentValidation<RegisterStudentCommand> ,并初始化相应的命令,这里可以看到,我们可以很自由针对某一个命令,随心随意的设计不同的验证,而且很好的进行管控,比如以后我们不要对名字控制了,我们只需要去掉这个方法。亦或者我们以后不仅支持手机号,还支持座机,这里就可以简单的增加一个即可。

namespace Christ3D.Domain.Validations
{
    /// <summary>
    /// 添加学生命令模型验证
    /// 继承 StudentValidation 基类
    /// </summary>
    public class RegisterStudentCommandValidation : StudentValidation<RegisterStudentCommand>
    {
        public RegisterStudentCommandValidation()
        {
            ValidateName();//验证姓名
            ValidateBirthDate();//验证年龄
            ValidateEmail();//验证邮箱
            ValidatePhone();//验证手机号
            //可以自定义增加新的验证
        }
    }
}

 

说到了这里,相信你应该也命令了领域驱动的第一个小部分了,就是我们的每一个操作是如何生成命令并进行验证的,那聪明的你一定会问了,我们如何操作这些领域命令呢,总得有一个驱动程序吧,它们自己肯定是不会运行的,不错!请继续往下看。

 

 

三、运筹命令模型 —— 谁会是指挥官?

上边也说到了视图模型转成命令模型,然后在命令模型中进行验证,现在问题来了,到底是谁在运筹着这些命令,说人话就是,是谁在调用着这些命令,如果你能看懂我说到,那就恭喜你,如果不是很懂,也没关系,今天咱们先不说这个指挥官,今天先说说,我们平时是怎么玩儿的。

1、在 Action 中调用我们的领域命令

 

[HttpPost]
[ValidateAntiForgeryToken]
public ActionResult Create(StudentViewModel studentViewModel)
{
    try
    {
        ViewBag.ErrorData = null;
        // 视图模型验证
        if (!ModelState.IsValid)
            return View(studentViewModel);

        //添加命令验证,采用构造函数方法实例
        RegisterStudentCommand registerStudentCommand = new RegisterStudentCommand(studentViewModel.Name, studentViewModel.Email, studentViewModel.BirthDate, studentViewModel.Phone);
        
        //如果命令无效,证明有错误
        if (!registerStudentCommand.IsValid())
        {
            List<string> errorInfo = new List<string>();
            //获取到错误,请思考这个Result从哪里来的 
            foreach (var error in registerStudentCommand.ValidationResult.Errors)
            {
                errorInfo.Add(error.ErrorMessage);
            }
            //对错误进行记录,还需要抛给前台
            ViewBag.ErrorData = errorInfo;
            return View(studentViewModel);
        }
        // 执行添加方法
        _studentAppService.Register(studentViewModel);
        ViewBag.Sucesso = "Student Registered!";
        return View(studentViewModel);
    }
    catch (Exception e)
    {
        return View(e.Message);
    }
}

这个很好理解,就是普通的调用,这里有两个问题,可以有助于大家是否真正理解:

1、new RegisterStudentCommand() 为什么是构造函数实例?

2、ValidationResult.Errors 错误信息是从哪里得到的?

如果这两个看懂了,给自己一个攒👍吧。这个时候,我们就需要把信息抛给前台了,怎么进行展示呢,这里我用的是自定义视图组件,如果你会可以快速看一遍,如果没有用过,请仔细看看。

 

2、自定义局部视图页面

添加一个视图组件类

 在 Web 根目录下新建文件夹 ViewComponents,然后添加视图组件类 AlertsViewComponent.cs

namespace Christ3D.UI.Web.ViewComponents
{
    public class AlertsViewComponent : ViewComponent
    {
        /// <summary>
        /// Alerts 视图组件
        /// 可以异步,也可以同步,注意方法名称,同步的时候是Invoke
        /// 我写异步是为了为以后做准备
        /// </summary>
        /// <returns></returns>
        public async Task<IViewComponentResult> InvokeAsync()
        {
            var notificacoes = await Task.Run(() => (List<string>)ViewBag.ErrorData);
            //遍历错误信息,赋值给 ViewData.ModelState
            notificacoes?.ForEach(c => ViewData.ModelState.AddModelError(string.Empty, c));
            return View();
        }
    }
}

每一个视图组件一个类,固定写法,这个其实就像mvc的controller。那我们还需要配置 view,如何配置呢,请往下看。

 

设计视图页面

 这里我是手动创建,不知道有没有快捷键,有知道的请留言哈

在 Views -> Shared 文件夹下,新建 Components\alerts\Default.cshtml 文件

@if (ViewData.ModelState.ErrorCount > 0)
{
    <div class="alert alert-danger">
        <button type="button" class="close" data-dismiss="alert">×</button>
        <h3 id="msgRetorno">Alert! Something went wrong:</h3>
            <div asp-validation-summary="ModelOnly" class="text-danger"></div>
    </div>
}

@if (!string.IsNullOrEmpty(ViewBag.Sucesso))
{
    <div class="alert alert-success">
        <button type="button" class="close" data-dismiss="alert">×</button>
        <h3 id="msgRetorno">@ViewBag.Sucesso</h3>
    </div>
}   

 

在主页面内调用

这里有两种办法:

 @* 将经典验证摘要替换为自定义视图组件作为标记助手 *@

 @*方式一(可用,但不推荐) @await Component.InvokeAsync("Alerts")*@

 <!-- 如果使用这个方法,请记得在_ViewImports.cshtml 中,导入@addTagHelper "*, Christ3D.UI.Web" -->
 <vc:alerts />

我个人推荐使用第二种方法,注意 alerts,是我们的视图名称。

 

 

如果你想了解更多关于自定义视图组件的知识,可以查看官网

1、https://docs.microsoft.com/zh-cn/aspnet/core/mvc/views/view-components?view=aspnetcore-2.1

 

3、浏览效果

 

 这个时候,我们已经把视图模型,命令模型,命令验证等连接在一起,也实现了我们的目的,看似很正常,其实问题还有很多:

这个指挥官真的指挥的很好么?

为何contrller中还是会存在业务逻辑?

等等。。。

 

四、鸣金…

 眼看时间已经很晚,今天就暂时写到这里了。

这个时候你一定会发现,这种异常数据的写法真的很不舒服,我们设计DDD领域驱动设计,目的就是为了要以领域为核心,把业务逻辑分离出去,这个虽然用到了领域命令,和命令验证,咋看分离出去了,但是调用的时候,还是没有把视图模型和命令模型穿起来,而且细心的你应该也发现了,我们的Service方法中,还是使用的领域模型,这个是不对的。那我们如何才能把视图模型,领域模型,验证模型和命令模型穿起来呢,又是如何很好的把获取错误信息从controller拨离出来呢,请听下回分解~

 

 

五、GitHub & Gitee

https://github.com/anjoy8/ChristDDD

https://gitee.com/laozhangIsPhi/ChristDDD