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

阅读量：5077 次

发布时间：2019-06-12

本文共 11288 字，大约阅读时间需要 37 分钟。

烽烟

哈喽大家周二好呀，咱们又见面了，上周末掐指一算，距离 圣诞节 只有 5 周的时间了（如果你还不知道为啥我要提圣诞节这个时间点，可以看看我的第二系列开篇《》），然后我简单的思考了下这个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 方法简单写下，你就知道多么简洁了，具体的会在下面两篇文章中说到：

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

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

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

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

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

更新

有的小伙伴，可能看本文或者其他的概念的时候，比较懵懂，我这里根据自己的理解，简单画了个草图，当然等系列结束的时候，还是有完整的，这里先来一个简单的：

零、今天实现棕色的部分

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

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

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

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

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

1、创建命令抽象基类

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

namespace Christ3D.Domain.Core.Commands{    ///     /// 抽象命令基类    /// 
    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{    ///     /// 定义一个抽象的 Student 命令模型    /// 继承 Command    /// 这个模型主要作用就是用来创建命令动作的，不是用来实例化存数据的，所以是一个抽象类    /// 
    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、基于命令模型，创建各种动作指令

上边的模型创造出来了，咱们需要用它来实现各种动作命令了，比如 CUD 操作（Create/Update/Delete），肯定是没有 R（Read）查询的。这里就重点说一下创建吧，剩下两个都一样。

namespace Christ3D.Domain.Commands{    ///     /// 注册一个添加 Student 命令    /// 基础抽象学生命令模型    /// 
    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{    ///     /// 定义基于 StudentCommand 的抽象基类 StudentValidation    /// 继承 抽象类 AbstractValidator    /// 注意需要引用 FluentValidation    /// 注意这里的 T 是命令模型    /// 
    /// 
     
      泛型类
         public abstract class StudentValidation
     
       : AbstractValidator
      
        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{    ///     /// 添加学生命令模型验证    /// 继承 StudentValidation 基类    /// 
    public class RegisterStudentCommandValidation : StudentValidation
     
          {        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
     
       errorInfo = new List
      
       ();            //获取到错误，请思考这个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    {        ///         /// Alerts 视图组件        /// 可以异步，也可以同步，注意方法名称，同步的时候是Invoke        /// 我写异步是为了为以后做准备        /// 
        /// 
             public async Task
     
       InvokeAsync()        {            var notificacoes = await Task.Run(() => (List
      
       )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){    
             
              
      Alert! Something went wrong:
            
      
    
     
}@if (!string.IsNullOrEmpty(ViewBag.Sucesso)){    
             
              
      @ViewBag.Sucesso
    
     
}

在主页面内调用

这里有两种办法：

@* 将经典验证摘要替换为自定义视图组件作为标记助手 *@ @*方式一(可用，但不推荐) @await Component.InvokeAsync("Alerts")*@

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

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

1、

3、浏览效果

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

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

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

等等。。。

四、鸣金...

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

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