烽烟
哈喽大家周二好呀，咱们又见面了，上周末掐指一算，距离 圣诞节 只有 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拨离出来呢，请听下回分解~
