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

上一篇:《IDDD 实现领域驱动设计-CQRS(命令查询职责分离)和 EDA(事件驱动架构)》 学习架构知识,需要有一些功底和经验,要不然你会和我一样吃力,C

上一篇:《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 系列(初级):