OEA 中的业务控制器设计模式

时间:2022-08-31 13:11:36

对于业务逻辑的组织,个人认为,最好是使用 DDD(《Domain Driven Design》) 的方式。DDD 使用领域模型来表达实体间的关系,同时在应用层使用 Service 来组织各实体间的过程式代码。二者构成了整个应用程序的核心业务逻辑(《Pattern of Enterprise Application Architecture》)。

 

OEA 是一个基于 DDD 思想的框架。在 OEA 中,使用了 Service、Controller 来组织过程式逻辑。结构如下图:
OEA 中的业务控制器设计模式

对于大型系统来说,OEA 中的 Service 主要作为分布式调用、本地调用的 Facade 接口,主要的业务过程则使用 Controller 来编写。对于小型系统来说,则可以直接把业务过程逻辑都编写在 Service 中。

 

在设计 Controller 时,应该特别注意两点:
* 扩展点:Controller 中表达业务过程行为的过程式方法,可以被扩展。这种扩展不应该改动调用方的代码。
* 单向依赖:Controller 之间应该是单向依赖的。否则,将会造成业务逻辑混乱。

 

我以最近编写的一个仓库管理产品的类图,来说明如何设计,能更好地达到以上两点:
OEA 中的业务控制器设计模式

该仓库管理产品的业务逻辑使用 Controller 组织。在编写完成产品后,可以编写扩展程序集,为产品主干程序集中的业务逻辑编写扩展。
Client:主干程序集中的客户端程序,它调用服务完成分布式调用逻辑。
Service:主干程序集中的服务程序,它调用工厂创建 ReceiveController 来间接完成入库逻辑。
ReceiveController:主干程序集中的入库业务控制器,它会组织入库相关的各个领域模型(如仓库、货品等),来完成相关业务。
ReceiveControllerExt:扩展程序集中的入库业务控制器。它继承自主干程序集中的 ReceiveController,并重写了基中的 Receive 方法,提供了新的入库业务逻辑。
MoveController:主干程序集中的移库业务控制器。它依赖入库控制器,需要在入库业务控制器中货品到达后,执行它指定的移库逻辑。入库控制器不能依赖移库控制器,这样,某些场景下,就可以把移库控制器去除,以达到简单入库、不执行移库逻辑的目的。
OEA.Controller: 框架提供的控制器基类,“层基类模式”。
OEA.ControllerFactory:框架提供的控制器工厂。使用工厂模式封装了所有业务控制器的构造过程,提供以下功能:
1. 具体控制器的创建。
创建具体子类的控制器,而不需要修改调用方代码。例如:当 Service 指定构造 ReceiveController 时,如果已经加载了 ReceiveControllerExt 类型扩展,则 ControllerFactory 会返回 ReceiveControllerExt 类型的实例,使得执行被扩展后的业务逻辑。
2. 控制器事件的自动挂接。
控制器声明所依赖的其它控制器,框架会自动调用其相关的挂接程序。例如:MoveController 依赖 ReceiveController,并使用 ControllerFactory 中的方法来声明需要监听 ReceiveController 中的 Received 事件。则 ControllerFactory 在创建 ReceiveController 时,也会创建一个 MoveController 的实例,并使其挂接到 ReceiveController.Received 事件上。这样就不需要改动 ReceiveController 的代码。

 

其实,整个设计主要是使用“简单工厂模式”来封装了业务控制器的构造过程,而达到扩展的效果。
不过由于在面向对象设计中,虚方法扩展、事件扩展是最常用的扩展设计(《Framework Design Guidelines 2nd Edition》),而同时业务控制器的设计基本上都需要这两类扩展,所以总结一下这个常用的控制器设计,以方便使用。

 

 

 

 

--------------------------------

附,使用此方案后,整个仓库系统中 Controller 的重构成果如下。解耦前:

OEA 中的业务控制器设计模式

解耦后:

OEA 中的业务控制器设计模式

 

简化图,解耦前:

OEA 中的业务控制器设计模式

解耦后:

OEA 中的业务控制器设计模式