转载

IDDD 实现领域驱动设计－一个简单的 CQRS 示例

上一篇：《 IDDD 实现领域驱动设计－CQRS（命令查询职责分离）和 EDA（事件驱动架构）》

学习架构知识，需要有一些功底和经验，要不然你会和我一样吃力，CQRS、EDA、ES、Saga 等等，这些是实践 DDD 所必不可少的架构，所以，如果你不懂这些，是很难看懂上篇所提到的 CQRS Journey 和 ENode 项目，那怎么办呢？我们可以从简单的 Demo 一点一滴开始。

代码地址： https://github.com/yuezhongxin/CQRS.Sample

说明：一张很丑陋的图

CQRS.Sample 所描述的一个流程是 SendMessage（发消息），也就是之前 MessageManager 中的一个业务示例，这个业务流程用到 CQRS 示例中，可能会有些不太准确，或者是有些牵强，但我主要的目的是想做一次 Commond->Event 的过程，熟悉它们到底是怎么交互的？所以，你查看代码的时候，尽量忽略这个业务流程，当然，如果你有针对这个业务流程更好的具体应用，我是非常欢迎交流。

首先，我们根据上面的流程图一步一步进行，UI 创建一个 Commond，然后交给 CommandBus 进行 Send（发送），也就是下面这段代码：

var commond = new SendMessageCommond() {  Title = "this is title",  Content = "this is content",  SenderLoginName = "this is senderLoginName",  RecipientDisplayName = "this is recipientDisplayName" }; var commandBus = IocContainer.Default.Resolve<CommandBus>(); commandBus.Send(commond);

项目中所有的类型映射都是通过 IoC 进行注入，ICommandBus 接口定义为： void Send<TCommand>(TCommand cmd) where TCommand : ICommand; ，CommandBus 的实现主要是在 Send 方法中，解析 ICommandHandler<TCommand> 注入的类型对象，然后调用 ICommandHandler 接口定义的 Handle 方法，传入 TCommand 参数对象。

SendMessageCommond 的定义很简单，主要是一些来自 UI 的参数，所以，我们一般会定义一些属性字段，有时候我们会进行数据验证，可以使用 Validate，方法签名是： IEnumerable<ValidationResult> Validate(ValidationContext validationContext) ，不过需要继承 IValidatableObject 接口，这样我们就可以在 MVC View 前端进行输出验证结果，使用起来非常方便，SendMessageCommond 继承一个无实现的 ICommand 接口，主要用来约束类型，SendMessageCommond 对应 SendMessageCommondHandler，实现代码：

public class SendMessageCommondHandler :   ICommandHandler<SendMessageCommond> {  public void Handle(SendMessageCommond command)  {   var sender = VerifySenderService.Verify(command.SenderLoginName);   var receiver = VerifyReceiverService.Verify(command.RecipientDisplayName);   var message = new Message(command.Title, command.Content, sender, receiver);   message.Send();  } }

CommondHandler 的功能有点类似于经典分层架构中的 Application（应用层），从它的具体实现中，我们就可以看出领域到底在做哪些工作，它的主要工作就是协调这些工作的流程，领域中的代码我就不贴了，这里我简单说明一下，在之前的 SendMessage 实现中，设计了一个 SendMessageService 领域服务，里面主要进行的工作是验证收发件人，以及消息是否符合规则，后来我就想，SendMessageService 和它实际进行的工作不相符，发消息所蕴含的实际业务意义，我也一直没有想明白，但是在具体实现中，发消息所做的工作是验证，那验证是不是发消息真正的业务含义呢？所以，稀里糊涂就有了上面的代码，VerifySenderService 和 VerifyReceiverService 是用来验证收发件人信息的，成功的话就返回一个 Contact 对象，具体的验证逻辑可以查看下实现代码。

下面说一下 message.Send(); ，这个可能有很大的问题，在 CQRS Journey 项目中，有很多类似于这样的操作，就是在 CommondHandler 中，创建一个聚合根对象，然后执行聚合根中的一个行为，比如我搜刮的 order.Confirm() ，订单可以提交自己吗？消息可以发送自己吗？这样做的含义是什么？其实我也搞不太清楚，在 Message 聚合根中的 Send 方法中，主要是事件的发布，

public void Send() {     eventBus.Publish(new MessageSentEvent(this)); }

先抛开 Send 的合理性，看下 EventBus 是如何 Publish 的？我的实现中和 CommondBus 很相似，但我觉得可能有些问题，Commond 和 CommondHandler 是一一对应关系，我们知道事件发布和事件订阅是一对多关系，也就是说一个事件可能有很对的订阅者，这些订阅者所处理的过程可能会有些不同，比如用户注册的一个事件，可能会有邮件通知订阅者，也可能会有统计数据更新订阅者，在 CQRS Journey 项目中，EventBus 的 Publish 大概是这样实现的：

public void Publish(Envelope<IEvent> @event) {  var message = this.BuildMessage(@event);  this.sender.Send(message); } private Message BuildMessage(Envelope<IEvent> @event) {  using (var payloadWriter = new StringWriter())  {   this.serializer.Serialize(payloadWriter, @event.Body);   return new Message(payloadWriter.ToString(), correlationId: @event.CorrelationId);  } }

而我的实现则是和 CommondBus 一样，都是用 IoC 注入的，所以肯定有问题，我们来看下 MessageSentEventHandler 中的代码：

public class MessageSentEventHandler :   IEventHandler<MessageSentEvent>,  IEventHandler<MailSentEvent> {  private IEventBus eventBus;  public void Handle(MessageSentEvent @event)  {   eventBus = IocContainer.Default.Resolve<IEventBus>();   new MessageRepository().Save<Message>(@event.Message);   eventBus.Publish(new MailSentEvent   {    Title = @event.Message.Title,    Content = @event.Message.Title,   });  }  public void Handle(MailSentEvent @event)  {   var mailMessage = new System.Net.Mail.MailMessage();   mailMessage.Subject = @event.Title;   mailMessage.Body = @event.Content;   mailMessage.IsBodyHtml = true;   mailMessage.BodyEncoding = System.Text.Encoding.UTF8;   mailMessage.Priority = System.Net.Mail.MailPriority.Normal;   System.Net.Mail.SmtpClient smtpClient = new System.Net.Mail.SmtpClient();   Task.Run(() => { smtpClient.SendAsync(mailMessage, mailMessage.Body); });  } }

消息发送之后，进行持久化操作，然后再进行邮件通知，这样一整个 SendMessage 的流程就走完了。

这个流程中，只有 CQRS 的 Commond，并没有 Query，也没有 ES、Saga 的概念，主要是它们太深奥了，我搞不来。CQRS.Sample 只是一个简单的示例，发消息的业务含义所表达的可能不是很准确，本来是想用用户注册、订单提交业务示例，但还是想想用发消息进行尝试下，除去 EventBus 的实现有问题，CQRS 的简化版基本上都能表现出来了。

另外，从简单分层架构改造成 CQRS 确实有很多挑战，但有时候想想，领域模型都设计的有问题，那用什么架构实现都毫无意义，如果在现有的项目中，你发现经典分层架构实现起来有很多别扭的地方，比如 Domain 引用了 DTO，你可以尝试先把 Repositories 进行分离下，创建一个 Query 项目，把一些无业务逻辑的查询发到里面（主要是应用层调用的），这样使 Repositories 更加简化，如果可以简化成只有一个 GetById 方法，那么就达到 CQRS 的标准了，因为 Repositories 的接口定义在领域层，因为 Query 项目的分离，所以，Domain 就可以去除 DTO 的引用了，应用层也就直接调用 Query，这只是一个中和方案。

领域模型需要一点一滴设计，架构也需要一点一滴设计，但后者需要建立在前者的基础上。

一个对我非常有帮助的 CQRS 系列（初级）：

正文到此结束

所属分类：编程技术

本文标签： node UI 参数 cmd cat DOM tab 解析 https HTML git App ip 代码 mail GitHub db 数据一对多
版权声明： 本文为互联网转载文章，出处已在文章中说明(部分除外)。如果侵权，请联系本站长删除，谢谢。
本文海报： 生成海报一生成海报二