oea 是一个基于 ddd 思想的框架。在 oea 中，使用了 service、controller 来组织过程式逻辑。结构如下图：
对于大型系统来说，oea 中的 service 主要作为分布式调用、本地调用的 facade 接口，主要的业务过程则使用 controller 来编写。对于小型系统来说，则可以直接把业务过程逻辑都编写在 service 中。
在设计 controller 时，应该特别注意两点：
* 扩展点：controller 中表达业务过程行为的过程式方法，可以被扩展。这种扩展不应该改动调用方的代码。
* 单向依赖：controller 之间应该是单向依赖的。否则，将会造成业务逻辑混乱。
我以最近编写的一个仓库管理产品的类图，来说明如何设计，能更好地达到以上两点：
该仓库管理产品的业务逻辑使用 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 的代码。
其实，整个设计主要是使用“简单工厂模式”来封装了业务控制器的构造过程，而达到扩展的效果。
--------------------------------
附，使用此方案后，整个仓库系统中 controller 的重构成果如下。解耦前：
解耦后：
简化图，解耦前：