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，实现消息的消费。