从壹开始微服务 [ 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、基于命令模型，创建各种动作指令

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

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拨离出来呢，请听下回分解~