缘起
哈喽小伙伴周三好，老张又来啦，DDD领域驱动设计的第二个D也快说完了，下一个系列我也在考虑之中，是 Id4 还是 Dockers 还没有想好，甚至昨天我还想，下一步是不是可以写一个简单的Angular 入门教程，本来是想来个前后端分离的教学视频的，简单试了试，发现自己的声音不好听，真心不好听那种，就作罢了，我看博客园有一个大神在 Bilibili 上有一个视频，具体地址忘了，有需要的留言，我找找。不过最近年底了比较累了，目前已经写了15万字了（一百天，平均一天1500字），或者看看是不是给自己放一个假吧，自己也找一些书看一看，给自己充充电，希望大家多提一下建议或者帮助吧。
言归正传，在上一篇文章中《之十 ║领域驱动【实战篇·中】：命令总线Bus分发（一）》，我主要是介绍了，如果通过命令模式来对我们的API层（这里也包括应用层）进行解耦，通过命令分发，可以很好的解决在应用层写大量的业务逻辑，以及多个对象之间混乱的关联的问题。如果对上一篇文章不是很记得了，我这里简单再总结一下，如果你能看懂这些知识点，并心里能大概行程一个轮廓，那可以继续往下看了，如果说看的很陌生，或者想不起来了，那请看上一篇文章吧。上篇文章有以下几个小点：
1、什么是中介者模式？以及中介者模式的原理？（提示：多对象不依赖，但可通讯）
2、MediatR 是如何实现中介者服务的？常用哪两种方法？（提示：请求/响应）
3、工作单元是什么？作用？（提示：事务）
这些知识点都是在上文中提到的，可能说的有点儿凌乱，不知道是否能看懂，上篇遗留了几个问题，所以我就新开了一篇文章，来重点对上一篇文章进行解释说明，大家可以看看是否和自己想的一样，欢迎来交流。
当然还是每篇一问，也是本文的提纲：
1、我们是如何把一个Command命令，一步步走到持久化的？
2、你自己能画一个详细的流程草图么？
零、今天实现左下角浅紫色的下框部分
（昨天的故事中，说到了，咱们已经建立了一个基于 MediatR 的在缓存中的命令总线，我们可以在任何一个地方通过该总线进行命令的分发，然后我们在应用层 StudentAppService.cs 中，对添加StudentCommand进行了分发，那我们到底应该如何分发，中介者又是如何调用的呢， 今天我们就继续接着昨天的故事往下说... ）
一、创建命令处理程序 CommandHandlers
咱们先把处理程序做出来，具体是如何执行的，咱们下边会再说明。
1、添加一个命令处理程序基类 CommandHandler.cs
namespace Christ3D.Domain.CommandHandlers
{
/// <summary>
/// 领域命令处理程序
/// 用来作为全部处理程序的基类，提供公共方法和接口数据
/// </summary>
public class CommandHandler
{
// 注入工作单元
private readonly IUnitOfWork _uow;
// 注入中介处理接口（目前用不到，在领域事件中用来发布事件）
private readonly IMediatorHandler _bus;
// 注入缓存，用来存储错误信息（目前是错误方法，以后用领域通知替换）
private IMemoryCache _cache; /// <summary>
/// 构造函数注入
/// </summary>
/// <param name="uow"></param>
/// <param name="bus"></param>
/// <param name="cache"></param>
public CommandHandler(IUnitOfWork uow, IMediatorHandler bus, IMemoryCache cache)
{
_uow = uow;
_bus = bus;
_cache = cache;
} //工作单元提交
//如果有错误，下一步会在这里添加领域通知
public bool Commit()
{
if (_uow.Commit()) return true; return false;
}
}
}
这个还是很简单的，只是提供了一个工作单元的提交，下边会增加对领域通知的伪处理。
2、定义学生命令处理程序 StudentCommandHandler.cs
namespace Christ3D.Domain.CommandHandlers
{
/// <summary>
/// Student命令处理程序
/// 用来处理该Student下的所有命令
/// 注意必须要继承接口IRequestHandler<,>，这样才能实现各个命令的Handle方法
/// </summary>
public class StudentCommandHandler : CommandHandler,
IRequestHandler<RegisterStudentCommand, Unit>,
IRequestHandler<UpdateStudentCommand, Unit>,
IRequestHandler<RemoveStudentCommand, Unit>
{
// 注入仓储接口
private readonly IStudentRepository _studentRepository;
// 注入总线
private readonly IMediatorHandler Bus;
private IMemoryCache Cache; /// <summary>
/// 构造函数注入
/// </summary>
/// <param name="studentRepository"></param>
/// <param name="uow"></param>
/// <param name="bus"></param>
/// <param name="cache"></param>
public StudentCommandHandler(IStudentRepository studentRepository,
IUnitOfWork uow,
IMediatorHandler bus,
IMemoryCache cache
) : base(uow, bus, cache)
{
_studentRepository = studentRepository;
Bus = bus;
Cache = cache;
} // RegisterStudentCommand命令的处理程序
// 整个命令处理程序的核心都在这里
// 不仅包括命令验证的收集，持久化，还有领域事件和通知的添加
public Task<Unit> Handle(RegisterStudentCommand message, CancellationToken cancellationToken)
{
// 命令验证
if (!message.IsValid())
{
// 错误信息收集
NotifyValidationErrors(message);
return Task.FromResult(new Unit());
} // 实例化领域模型，这里才真正的用到了领域模型
// 注意这里是通过构造函数方法实现
var customer = new Student(Guid.NewGuid(), message.Name, message.Email, message.Phone, message.BirthDate); // 判断邮箱是否存在
// 这些业务逻辑，当然要在领域层中（领域命令处理程序中）进行处理
if (_studentRepository.GetByEmail(customer.Email) != null)
{
//这里对错误信息进行发布，目前采用缓存形式
List<string> errorInfo = new List<string>() { "The customer e-mail has already been taken." };
Cache.Set("ErrorData", errorInfo);
return Task.FromResult(new Unit());
} // 持久化
_studentRepository.Add(customer); // 统一提交
if (Commit())
{
// 提交成功后，这里需要发布领域事件
// 比如欢迎用户注册邮件呀，短信呀等 // waiting....
} return Task.FromResult(new Unit()); } // 同上，UpdateStudentCommand 的处理方法
public Task<Unit> Handle(UpdateStudentCommand message, CancellationToken cancellationToken)
{
// 省略...
} // 同上，RemoveStudentCommand 的处理方法
public Task<Unit> Handle(RemoveStudentCommand message, CancellationToken cancellationToken)
{
// 省略...
} // 手动回收
public void Dispose()
{
_studentRepository.Dispose();
}
}
}
3、注入我们的处理程序
在我们的IoC项目中，注入我们的命令处理程序，这个时候，你可能有疑问，为啥是这样的，下边我讲原理的时候会说明。
// Domain - Commands
services.AddScoped<IRequestHandler<RegisterStudentCommand, Unit>, StudentCommandHandler>();
services.AddScoped<IRequestHandler<UpdateStudentCommand, Unit>, StudentCommandHandler>();
services.AddScoped<IRequestHandler<RemoveStudentCommand, Unit>, StudentCommandHandler>();
好啦！这个时候我们已经成功的，顺利的，把由中介总线发出的命令，借助中介者 MediatR ，通过一个个处理程序，把我们的所有命令模型，领域模型，验证模型，当然还有以后的领域事件，和领域通知联系在一起了，只有上边两个类，甚至说只需要一个 StudentCommandHandler.cs 就能搞定，因为另一个 CommandHandler 仅仅是一个基类，完全可以合并在 StudentCommandHandler 类里，是不是感觉很神奇，如果这个时候你没有感觉到他的好处，请先停下往下看的眼睛，仔细思考一下，如果我们不采用这个方法，我们会是怎么的工作：
在 API 层的controller中，进行参数验证，然后if else 判断，
接下来在服务器中写持久化，然后也要对持久化中的错误信息，返回到 API 层；
不仅如此，我们还需要提交成功后，进行发邮件，或者发短信等子业务逻辑（当然这一块，咱们还没实现，不过已经挖好了坑，下一节会说到。）；
最后，我们可能以后会说，添加成功和删除成功发的邮件方法不一样，甚至还有其他；
现在想想，如果这样的工作，我们的业务逻辑需要写在哪里？毫无疑问的，当然是在API层和应用层，我们领域层都干了什么？只有简单的一个领域模型和仓储接口！那这可真的不是DDD领域驱动设计的第二个D —— 驱动。
但是现在我们采用中介者模式，用命令驱动的方法，情况就不是这样了，我们在API 层的controller中，只有一行代码，在应用服务层也只有两行；
var registerCommand = _mapper.Map<RegisterStudentCommand>(StudentViewModel);
Bus.SendCommand(registerCommand);
到这个时候，我们已经从根本上，第二次了解了DDD领域驱动设计所带来的不一样的快感（第一次是领域、聚合、值对象等相关概念）。当然可能还不是很透彻，至少我们已经通过第一条总线——命令总线，来实现了复杂多模型直接的通讯了，下一篇我们说领域事件的时候，你会更清晰。那聪明的你一定就会问了：
好吧，你说的这些我懂了，也大概知道了怎么用，那它们是如何运行的呢？不知道过程，反而无法理解其作用！没错，那接下来，我们就具体说一说这个命令是如何分发的，请耐心往下看。
二、基于源码分析命令处理过程
这里说的基于源码，不是一字一句的讲解，那要是我能说出来，我就是作者了