对于业务逻辑的组织，个人认为，最好是使用 DDD（《Domain Driven Design》） 的方式。DDD 使用领域模型来表达实体间的关系，同时在应用层使用 Service 来组织各实体间的过程式代码。二者构成了整个应用程序的核心业务逻辑（《Pattern of Enterprise Application Architecture》）。
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 的代码。
其实，整个设计主要是使用“简单工厂模式”来封装了业务控制器的构造过程，而达到扩展的效果。
不过由于在面向对象设计中，虚方法扩展、事件扩展是最常用的扩展设计（《Framework Design Guidelines 2nd Edition》），而同时业务控制器的设计基本上都需要这两类扩展，所以总结一下这个常用的控制器设计，以方便使用。
--------------------------------
附，使用此方案后，整个仓库系统中 Controller 的重构成果如下。解耦前：
解耦后：
简化图，解耦前：
解耦后：
本文转自BloodyAngel博客园博客，原文链接：http://www.cnblogs.com/zgynhqf/archive/2013/03/08/2949665.html，如需转载请自行联系原作者
