IDDD 实现领域驱动设计－一个简单的 CQRS 示例
学习架构知识，需要有一些功底和经验，要不然你会和我一样吃力，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 系列（初级）： CQRS实践(1): 什么是CQRS CQRS实践(2): Command的实现 CQRS实践(3): Command执行结果的返回 CQRS实践(4): 领域事件 本文转自田园里的蟋蟀博客园博客，原文链接：http://www.cnblogs.com/xishuai/p/iddd-cqrs-samlpe.html，如需转载请自行联系原作者
