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的思想。比如：
- ENode规定，一个Command不能同时修改两个聚合根，必须通过事件驱动的方式，先修改一个聚合根，然后该聚合根产生事件，然后另一个聚合根订阅响应事件，再修改自己的状态，从而实现两个聚合根之间的交互。这个思路 背后的原则是：聚合内强一致性、聚合之间最终一致性。
- CQRS两端，也是最终一致性，通过事件来同步数据。C端产生的事件通过MQ被Q端订阅，然后Q端更新自己的读库，从而实现数据的最终一致性；
- 两个BC（Bounded Context，上下文）之间的数据传递，也是基于消息驱动的思想。比如支付上下文在完成支付后，会产生一个消息，然后订单上下文订阅响应该消息，实现上下文之间的交互。
ENode架构图
也许有人没看过ENode架构图，呵呵。我这里再贴一下，谁如果要进一步了解ENode的架构设计，可以看我博客中的其他关于ENode框架的介绍文章。
Conference项目结构介绍
|
|
前篇文章中我们了解到，Conference案例共有三个上下文，分别是：会议管理（ConferenceManagement）、订单处理（Registration）、订单支付（Payment）。关于这个案例，微软的实现和我的实现有所不同，但上下文的划分是一致的。微软的实现中，三个上下文用的技术架构是不同的。
上面我简要分析了一下微软的实现。我觉得微软的实现还是非常有参考价值的，因为它充分展示了DDD中不同的BC可以采用不同的技术架构实现，然后通过EDA的整体架构，来实现3个BC之间的数据交互。非常棒。 下面我说一下ENode实现的Conference案例。 前面说过，本案例主要是为了展示ENode框架的使用，所以我给这3个BC都是使用ENode框架实现，所以每个BC都是采用的DDD+CQRS+ES的技术架构。由于有ENode框架的支持，所以代码实现还不算复杂，可以让开发只需要专注于业务逻辑的实现即可，不需要关心消息传递，消息不丢失，消息幂等处理，并发问题，C端数据持久化等技术问题。这些技术问题如果没有框架支持，要由应用开发人员自己实现，是很有难度的。通过这个案例实践下来，基本可以证明ENode框架是可以被使用来开发出一个可实际使用的项目的，这点我目前很有信心。 采用ENode框架开发一个BC的实现的时候，我们一般需要定义以下的一些工程：
另外，上面介绍了单个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到最后更新读库的整个代码链路简单介绍一下，方便读者能对实现某个功能要写哪些代码先有一个清晰总体的认识。