在Customer服务中，使用RabbitMQEventBus就非常简单了，只需要引用RabbitMQEventBus的程序集，然后在Startup.cs文件的ConfigureServices方法中，替换PassThroughEventBus的使用即可：
public void ConfigureServices(IServiceCollection services) { this.logger.LogInformation("正在对服务进行配置..."); services.AddMvc(); services.AddTransient<IEventStore>(serviceProvider => new DapperEventStore(Configuration["mssql:connectionString"], serviceProvider.GetRequiredService<ILogger<DapperEventStore>>())); var eventHandlerExecutionContext = new EventHandlerExecutionContext(services, sc => sc.BuildServiceProvider()); services.AddSingleton<IEventHandlerExecutionContext>(eventHandlerExecutionContext); // services.AddSingleton<IEventBus, PassThroughEventBus>(); var connectionFactory = new ConnectionFactory { HostName = "localhost" }; services.AddSingleton<IEventBus>(sp => new RabbitMQEventBus(connectionFactory, sp.GetRequiredService<ILogger<RabbitMQEventBus>>(), sp.GetRequiredService<IEventHandlerExecutionContext>(), RMQ_EXCHANGE, queueName: RMQ_QUEUE)); this.logger.LogInformation("服务配置完成，已注册到IoC容器！"); }Note：一种更好的做法是通过配置文件来配置IoC容器，在曾经的Microsoft Patterns and Practices Enterprise Library Unity Container中，使用配置文件是很方便的。这样只需要Customer服务能够通过配置文件来配置IoC容器，同时只需要让Customer服务依赖（注意，不是程序集引用）于不同的事件总线的实现即可，无需对Customer服务重新编译。
下面来验证一下效果。首先确保RabbitMQ已经配置并启动妥当，我是安装在本地机器上，使用默认安装。首先启动ASP.NET Core Web API，然后通过Powershell发起两次创建Customer的请求：
查看一下数据库是否更新正常：
并检查一下日志信息：
RabbitMQ中Exchange的信息：
本文提供了一种RabbitMQEventBus的实现，目前来说是够用的，而且这种实现是可以使用在实际项目当中的。在实际使用中，或许也会碰到一些与RabbitMQ本身有关的问题，这就需要具体问题具体分析了。此外，本文没有涉及事件消息丢失、重发然后保证最终一致性的问题，这些内容会在后面讨论。从下文开始，我们着手逐步实现CQRS架构的领域事件和事件存储部分。
源代码的使用本系列文章的源代码在https://github.com/daxnet/edasample这个Github Repo里，通过不同的release tag来区分针对不同章节的源代码。本文的源代码请参考chapter_3这个tag，如下：
欢迎访问我的博客新站：。