从壹开始微服务 [ DDD ] 之十一 ║ 基于源码分析，命令分发的过程（二）
缘起
哈喽小伙伴周三好，老张又来啦，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领域驱动设计所带来的不一样的快感（第一次是领域、聚合、值对象等相关概念）。当然可能还不是很透彻，至少我们已经通过第一条总线——命令总线，来实现了复杂多模型直接的通讯了，下一篇我们说领域事件的时候，你会更清晰。那聪明的你一定就会问了：
好吧，你说的这些我懂了，也大概知道了怎么用，那它们是如何运行的呢？不知道过程，反而无法理解其作用！没错，那接下来，我们就具体说一说这个命令是如何分发的，请耐心往下看。
二、基于源码分析命令处理过程
这里说的基于源码，不是一字一句的讲解，那要是我能说出来，我就是作者了😄，我就简单的说一说，希望大家能看得懂。
0、下载 MediatR 源码
既然要研究源码，这里就要下载相应的代码，这里有两个方式，
1、可以在VS 中下载 ReSharper ，可以查看反编译的所有代码，注意会比以前卡一些。
2、直接查看Github ，https://github.com/jbogard/MediatR/tree/master/src/MediatR，现在开源的项目是越来越多，既然人家开源了，咱们就不能辜负了他们的开源精神，所以下载下来看一看也是很不错。
本来我想把整个类库，添加到咱们的项目中，发现有兼容问题，想想还是算了，就把其中几个方法摘出来了，比如这个 Mediator.Send() 方法。
下边就是整体流程，
1、应用层的命令请求：
// 领域命令请求 Bus.SendCommand(registerCommand);
2、领域命令的包装
不知道大家还记得 MediatR 有哪两种常用方法，没错，就是请求/响应 Request/Response 和 发布 Publish 这两种，咱们的命令是用的第一种方法，所以今天就先说说这个 Mediator.Send() 。咱们在中介内存总线InMemoryBus.cs 中，定义了SendCommand方法，是基于IMediator 接口的，今天咱们就把真实的方法拿出来：
1、把源代码中 Internal 文件夹下的 RequestHandlerWrapper.cs 放到我们的基础设施层的 Christ3D.Infra.Bus 层中
从这个名字 RequestHandlerWrapper 中我们也能看懂，这个类的作用，就是把我们的请求领域命令，包装成指定的命令处理程序。
2、修改我们的内存总线方法
namespace Christ3D.Infra.Bus { /// <summary> /// 一个密封类，实现我们的中介内存总线 /// </summary> public sealed class InMemoryBus : IMediatorHandler { //构造函数注入 private readonly IMediator _mediator; //注入服务工厂 private readonly ServiceFactory _serviceFactory; private static readonly ConcurrentDictionary<Type, object> _requestHandlers = new ConcurrentDictionary<Type, object>(); public InMemoryBus(IMediator mediator, ServiceFactory serviceFactory) { _mediator = mediator; _serviceFactory = serviceFactory; } /// <summary> /// 实现我们在IMediatorHandler中定义的接口 /// 没有返回值 /// </summary> /// <typeparam name="T"></typeparam> /// <param name="command"></param> /// <returns></returns> public Task SendCommand<T>(T command) where T : Command { //这个是正确的 //return _mediator.Send(command);//请注意 入参 的类型 //注意！这个仅仅是用来测试和研究源码的，请开发的时候不要使用这个 return Send(command);//请注意 入参 的类型 } /// <summary> /// Mdtiator Send方法源码 /// </summary> /// <typeparam name="TResponse">泛型</typeparam> /// <param name="request">请求命令</param> /// <param name="cancellationToken">用来控制线程Task</param> /// <returns></returns> public Task<TResponse> Send<TResponse>(IRequest<TResponse> request, CancellationToken cancellationToken = default) { // 判断请求是否为空 if (request == null) { throw new ArgumentNullException(nameof(request)); } // 获取请求命令类型 var requestType = request.GetType(); // 对我们的命令进行封装 // 请求处理程序包装器 var handler = (RequestHandlerWrapper<TResponse>)_requestHandlers.GetOrAdd(requestType, t => Activator.CreateInstance(typeof(RequestHandlerWrapperImpl<,>).MakeGenericType(requestType, typeof(TResponse))));
//↑↑↑↑↑↑↑ 这以上是第二步 ↑↑↑↑↑↑↑↑↑↑
//↓↓↓↓↓↓↓ 第三步开始 ↓↓↓↓↓↓↓↓↓
// 执行封装好的处理程序 // 说白了就是执行我们的命令 return handler.Handle(request, cancellationToken, _serviceFactory); } } }
上边的方法的第二步中，我们获取到了 handler ，这个时候，我们已经把 RegisterStudentCommand 命令，包装成了 RequestHandlerWrapper<RegisterStudentCommand> ，那如何成功的定位到 StudentCommandHandler.cs 呢，请继续往下看。(你要是问我作者具体是咋封装的，请看源码，或者给他发邮件，说不定你还可以成为他的开发者之一哟 ~)
3、服务工厂调用指定的处理程序
我们获取到了 handler 以后，就去执行该处理程序
handler.Handle(request, cancellationToken, _serviceFactory);
我们看到 这个handler 还是一个抽象类 internal abstract class RequestHandlerWrapper<TResponse> ，接下来，我们就是通过 .Handle() ，对抽象类进行实现
上图的过程是这样：
1、访问类方法 handler.Handle() ；
2、是一个管道处理程序，要包围内部处理程序的管道行为，实现添加其他行为并等待下一个委托。
3、就是调用了这个匿名方法；
4、执行GetHandler() 方法；
其实从上边简单的看出来，就是实现了请求处理程序从抽象到实现的过程，然后添加管道，并下一步要对该处理程序进行实例化的过程，说白了就是把 RequestHandlerWrapper<RegisterStudentCommand> 给转换成 IRequestHandler<RegisterStudentCommand> 的过程，然后下一步给 new 了一下。可是这个时候你会问，那实例化，肯定得有一个对象吧，这个接口自己肯定无法实例化的，没错！如果你能想到这里，证明你已经接近成功了，请继续往下看。
4、通过注入，实例化我们的处理程序
在上边的步骤中，我们知道了一个命令是如何封装成了特定的处理程序接口，然后又是在哪里进行实例化的，但是具体实例化成什么样的对象呢，就是在我们的 IoC 中：
// Domain - Commands // 将命令模型和命令处理程序匹配 services.AddScoped<IRequestHandler<RegisterStudentCommand, Unit>, StudentCommandHandler>(); services.AddScoped<IRequestHandler<UpdateStudentCommand, Unit>, StudentCommandHandler>(); services.AddScoped<IRequestHandler<RemoveStudentCommand, Unit>, StudentCommandHandler>();
如果你对依赖注入很了解的话，你一眼就能明白这个的意义是什么：
依赖注入 services.AddScoped<A, B>();意思就是，当我们在使用或者实例化接口对象 A 的时候，会在容器中自动匹配，并寻找与之对应的类对象 B。说到这里你应该也就明白了，在第三步中，我们通过 GetInstance，对我们包装后的命令处理程序进行实例化的时候，自动寻找到了 StudentCommandHandler.cs 类。
5、匹配具体的命令处理方法
这个很简单，在第四步之后，紧接着就是自动寻找到了 Task<Unit> Handle(RegisterStudentCommand message, CancellationToken cancellationToken) 方法，整个流程就这么结束了。
现在这个流程你应该已经很清晰了，或者大概了解了整体过程，还有一个小问题就是，我们如何将错误信息收集的，在之前的Controller 里写业务逻辑的时候，用的是 ViewBag，那类库是肯定不能这么用的，为了讲解效果，我暂时用缓存替换，明天我们会用领域事件来深入讲解。
三、用缓存来记录错误通知
这里仅仅是一个小小的乱入补充，上边已经把流程调通了，如果你想看看什么效果，这里就出现了一个问题，我们的错误通知信息没有办法获取，因为之前我们用的是ViewBag，这里无效，当然Session等都无效了，因为我们是在整个项目的多个类库之间使用，只能用 Memory 缓存了。
1、命令处理程序基类CommandHandler 中，添加公共方法
//将领域命令中的验证错误信息收集 //目前用的是缓存方法（以后通过领域通知替换） protected void NotifyValidationErrors(Command message) { List<string> errorInfo = new List<string>(); foreach (var error in message.ValidationResult.Errors) { errorInfo.Add(error.ErrorMessage); } //将错误信息收集 _cache.Set("ErrorData", errorInfo); }
2、在Student命令处理程序中调用
3、自定义视图模型中加载
/// <summary> /// Alerts 视图组件 /// 可以异步，也可以同步，注意方法名称，同步的时候是Invoke /// 我写异步是为了为以后做准备 /// </summary> /// <returns></returns> public async Task<IViewComponentResult> InvokeAsync() { // 获取到缓存中的错误信息 var errorData = _cache.Get("ErrorData"); var notificacoes = await Task.Run(() => (List<string>)errorData); // 遍历添加到ViewData.ModelState 中 notificacoes?.ForEach(c => ViewData.ModelState.AddModelError(string.Empty, c)); return View(); }
这都是很简单，就不多说了，下一讲的领域事件，再好好说吧。
这个时候记得要在API的controller中，每次把缓存清空。
4、效果浏览
整体流程就是这样：
四、结语
上边的流程想必你已经看懂了，或者说七七八八，但是，至少你现在应该明白了，中介者模式，是如何通过命令总线Bus，把命令发出去，又是为什么在领域层的处理程序里接受到的，最后又是如何执行的，如果还是不懂，请继续看一看，或者结合代码，调试一下。我们可以这样来说，请求以命令的形式包裹在对象中，并传给调用者。调用者（代理）对象查找可以处理该命令的合适的对象，并把该命令传给相应的对象，该对象执行命令 。
如果你看到这里了，那你下一节的领域事件，就很得心应手，这里有两个问题遗留下来：
1、我们记录错误信息，缓存很不好，还需要每次清理，不是基于事务的，那如何替换呢？
2、MediatR有两个常用方法，一个是请求/响应模式，另一个发布模式如何使用么？
如果你很好奇，那就请看下回分解吧~~
五、GitHub & Gitee
https://github.com/anjoy8/ChristDDD
https://gitee.com/laozhangIsPhi/ChristDDD
--End
浙公网安备 33010602011771号