ENode框架Conference案例分析系列之 - 架构设计

Conference架构概述

先贴一下Conference案例的在线地址，UI因为完全拿了微软的实现，所以都是英文的，以后我有空再改为中文的。

• Conference后台会议管理：http://www.enode.me/conference
• Conference前台预定座位：http://www.enode.me/registration
• ENode论坛开源案例：http://www.enode.me/post
• ENode开源项目地址：https://github.com/tangxuehua/enode

前一篇文章介绍了Conference案例的上下文划分和领域模型的设计思路，本文想介绍一下Conference案例的架构设计。我做Conference案例的出发点是为了给大家展示如何使用ENode框架来开发DDD+CQRS+ES+EDA风格的应用程序。所以，Conference案例的架构自然就是使用这个架构了。下面我展开来说一下：

• DDD：是软件设计的一种方式，出发点是通过领域模型封装业务逻辑和业务规则，解决领域内的复杂业务问题；
• CQRS+ES：命令查询分离的架构，通过将命令查询分离，做到处理业务逻辑的部分和查询的部分可以分离，方便两部分可以各自发展，不受对方约束；CQRS的实现方式主要有两种：1）共享存储的CQRS，即背后的数据库存储是一份，数据是一份，只是在代码、架构层面做到命令和查询逻辑的分离。这种方式很好的利用了CQRS的思想，同时也不会有数据一致性的问题，因为是共享存储的，所以CQ两端不需要有消息通信，大部分应用程序用这种方式即可。2）存储分离的CQRS，这种方式主要用ES（Event Sourcing，事件溯源）技术来彻底实现CQ两端的完全分离，这种架构比较复杂。C端不存储对象的最新状态，而是存储对象产生的所有事件；让我们要还原一个对象时，通过ES的方式来还原。然后Q端通过订阅C端产生的事件来更新读库。这种架构是一种EDA的架构，CQ两端需要通过事件来进行联系，所以是一种面向最终一致性思路的架构。那这种方式有何好处呢？它和前面我说的第一种方式的CQRS架构，我觉得主要的好处是，我们可以设计一套框架，帮我们从架构层面解决并发问题、消息的幂等处理问题；同时结合in-memory, group commit等技术，还能大大提高系统的吞吐量以及抵御高峰的能力（因为消息可以堆积）；从而可以让开发人员不用关心技术问题，专心实现业务逻辑和设计业务流程即可。而共享存储的CQRS架构，是需要我们每次Command修改完聚合根之后，需要主动保存（可能通过ORM实现）聚合根的状态的。总之两种实现方式各有优缺点，关于CQRS架构的更多介绍，我博客里已经写过很多文章了，有兴趣的朋友可以进一步看看。
• EDA：这是一种事件驱动的架构，他和SOA架构属于同一个层次；EDA是事件驱动的思想，即B订阅A产生的消息来进行主动响应的思路；而SOA是一种面向服务然后通过服务之间相互调用（RPC）的思想；这是两种不同的架构风格，我们在不同的场景会使用不同的方式。ENode实现的是EDA架构，面向的是最终一致性。ENode在很多方面都体现出了EDA的思想。比如：
  1. ENode规定，一个Command不能同时修改两个聚合根，必须通过事件驱动的方式，先修改一个聚合根，然后该聚合根产生事件，然后另一个聚合根订阅响应事件，再修改自己的状态，从而实现两个聚合根之间的交互。这个思路 背后的原则是：聚合内强一致性、聚合之间最终一致性。
  2. CQRS两端，也是最终一致性，通过事件来同步数据。C端产生的事件通过MQ被Q端订阅，然后Q端更新自己的读库，从而实现数据的最终一致性；
  3. 两个BC（Bounded Context，上下文）之间的数据传递，也是基于消息驱动的思想。比如支付上下文在完成支付后，会产生一个消息，然后订单上下文订阅响应该消息，实现上下文之间的交互。

ENode架构图

也许有人没看过ENode架构图，呵呵。我这里再贴一下，谁如果要进一步了解ENode的架构设计，可以看我博客中的其他关于ENode框架的介绍文章。

Conference项目结构介绍

前篇文章中我们了解到，Conference案例共有三个上下文，分别是：会议管理（ConferenceManagement）、订单处理（Registration）、订单支付（Payment）。关于这个案例，微软的实现和我的实现有所不同，但上下文的划分是一致的。微软的实现中，三个上下文用的技术架构是不同的。 ConferenceManagement，由于只是后台管理系统，业务逻辑相对不是很复杂，所以，采用的是普通的三层结构； Registration，由于是整个系统的整个Conference系统的核心，业务逻辑和流程都比较负责，所以使用的是CQRS+ES的架构； Payment，由于Conference这个项目只是一个案例，所以其实没有真正实现支付的功能，只是简单示范了一下功能，所以这个上下文的业务逻辑也不太复杂。但是由于访问量也比较大，每个订单都会需要支付，所以也是采用的CQRS的架构，但是因为业务逻辑不复杂（不需要在存储层面也分离），所以没有采用ES技术。Payment聚合根里产生事件，最后Repository保存聚合根的最新状态，然后通过事件总线发布事件，通知Registration上下文订单支付结果。 上面我简要分析了一下微软的实现。我觉得微软的实现还是非常有参考价值的，因为它充分展示了DDD中不同的BC可以采用不同的技术架构实现，然后通过EDA的整体架构，来实现3个BC之间的数据交互。非常棒。 下面我说一下ENode实现的Conference案例。 前面说过，本案例主要是为了展示ENode框架的使用，所以我给这3个BC都是使用ENode框架实现，所以每个BC都是采用的DDD+CQRS+ES的技术架构。由于有ENode框架的支持，所以代码实现还不算复杂，可以让开发只需要专注于业务逻辑的实现即可，不需要关心消息传递，消息不丢失，消息幂等处理，并发问题，C端数据持久化等技术问题。这些技术问题如果没有框架支持，要由应用开发人员自己实现，是很有难度的。通过这个案例实践下来，基本可以证明ENode框架是可以被使用来开发出一个可实际使用的项目的，这点我目前很有信心。 采用ENode框架开发一个BC的实现的时候，我们一般需要定义以下的一些工程：  Commands，定义所有的命令； CommandHandlers，定义所有的CommandHandlers； Domain，就是对应DDD领域层； ReadModel，表示CQRS的Query Side的实现，主要包括query service的实现，以及event handler用户更新读库； Messages，定义了当前BC所有对外的消息，其他BC可以订阅这些消息；消息都是DTO。 MessagePublishers，该项目的职责是订阅当前BC内部的Domain Event，然后转换为Message，然后把Message发布出去，从而实现通知到其他的BC。之所以要定义出Message这种DTO，是因为，我认为DDD中的Domain Event最好不要跨BC，因为Domain Event是属于当前Domain的东西，Domain Event中可能会包括当前Domain里定义的各种值对象；如果直接发布到其他BC，就会导致BC的边界不清。 Repositories，这种工程的作用就是实现Domain里可能定义的仓储接口。为何使用ENode框架后，还需要定义仓储接口？因为有些情况下，我们需要有一些二级索引的检查，比如创建会议时，我们要判断会议的某个属性是唯一的，但是ES不支持二级索引，而我们又不能通过查询读库来判断唯一性。所以我们需要在C端设计一些存储聚合根索引信息的仓储，用来支持二级索引。左边的图里我把项目名称命名为Repositories.Dapper，说明这个仓储是用Dapper来实现的。如果我们用EF来实现，那可以命名为Repositories.EF。 ProcessManagers，这种项目是用来承载CQRS架构中的Saga的，即流程管理器。Saga的作用是对业务流程进行建模。Saga的原理也是事件驱动，一个Saga会响应事件，然后发送命令。通过事件+命令串联的方式实现事件驱动架构的业务流程。Saga（ProcessManager）是无状态的，所有的状态应该都在聚合根里。这点我和微软的Saga的设计也是不同的，有兴趣的朋友可以看一下微软的实现。 另外，上面介绍了单个BC内部可能出现的项目，这些项目是我通过做这个案例后总结出来的觉得可以给开发者做参考的相互划分方式。大家如果觉得这样的方式不好，可以自己决定如何划分。通过上面的划分，我们的顶层Web项目只需要依赖简单的Commands，ReadModel这两个项目，就可以实现命令的发送和读库数据的查询了。而BC之间的交互，另一个BC只需要依赖当前BC的Messages项目就行，做到了最小的依赖。 最后介绍一下剩余的几个顶层项目： Conference案例有两个Web项目，分别为用户提供Conference的后台管理和前台订单预定的Web界面。这个不需要多解释了应该。然后，还有3个ProcessorHost项目。这3个项目分别是3个BC负责处理后台业务逻辑的顶层宿主项目。它们只需要用控制台应用或者Windows服务的方式启动即可（案例里的实现同时支持这两种方式的启动，会自动识别当前的应用程序类型）。这3个后台服务，它们都是从EQueue订阅消息，然后处理消息的方式，实现自己的功能。所以它们的唯一数据来源就是EQueue。那EQueue消息队列的服务端是哪个呢？就是最下面的MessageBroker，这个项目承载了整个系统的消息中心，也就是EQueue的Broker。所有的消息都会发送给MessageBroker，然后相关的ProcessorHost订阅相关的Topic，实现消息的消费。

结尾

下一篇文章打算从代码的角度，以创建一个会议为例，从前台Controller到最后更新读库的整个代码链路简单介绍一下，方便读者能对实现某个功能要写哪些代码先有一个清晰总体的认识。