隔离的领域层

1. 目的

    将业务层的方法调用，变成非显式调用，有利于界面的自动化测试。

2. 动机

    在编写客户端代码的时候，很多Action 都是直接调用业务层方法（或者通过Presenter 负责调用），这样就会使界面的代码直接依赖业务层代码，在进行单元测试的时候会为业务层接口打很多的桩，工作量较大。而且界面的单元测试，主要是测试界面的布局、界面的逻辑和用户响应等，在单元测试阶段很少会涉及业务的逻辑。

3. 参与者

    1, Presentation： 主要负责界面的展现和用户操作的接受。

    2. Presenter： 主要负责用户的界面操作，转发用户的业务操作。

    3. Domain Binder： 主要负责连接表现层和领域逻辑层。

    4. Domain Accessor： 主要负责领域逻辑层的访问。

    5. Domain Logic： 主要负责处理业务逻辑。

4. 协作

   

说明：   

    1.图中的虚线为非显式调用；

    2.图中的实线为直接方法调用；

5. 实现

    实现流程图如下：

 

    由于只能加3个附件，所以其它流程图不能够加进来，具体可能参见源代码吗？

5. 结果

    表现层不直接依赖领域层，用户在进行业务操作时，Presenter 会将业务操作封装成一个Domain Event 发到Domain Accessor。 Domain Event 封装了操作的类型和参数。当系统需要多客户端同步时，Domain Accessor 会接收到领域层发来的事件，然后再将该事件转换成Domain Event 发出去，表现层会收到事件然后作相应的处理。

6. 特点

    优点：该模式有利于界面的单元测试或自动化测试，也使开发界面的人不关心业务逻辑，开发业务逻辑的人不关心界面，有利于合理的分工；

    缺点：用户操作被抽象成一个Domain Event，会使结构变的复杂，很难被理解。

7. 感谢

    感谢shaucle和BirdGu，他们提供了很多建设性的意见。

没有人关心吗？如果有意见的可以提呀？

不错啊，事件驱动，可更大程度地实现松散偶合．

hibernate就是这么做的．

这样做当然可以实现松散耦合，但是也会使程序变得复杂，我正在应用该模式，如果哪位应用过可以共享一下。

俺倒是不这么认为，很多时候会更使程序模块更清晰，
当然很简单的逻辑没必要

它的复杂性主要体现在两个方面：
1.业务方法的调用变成了字符串，而非直接调用，这样对后期的维护会很复杂，因为通过开发工具不能够找到某个业务方法被谁调用，在Refactor 时也会出现问题。
2.业务方法的调用都是通过反射进行调用的，对开发阶段的调试也是比较复杂的。

这样的框架我见多了，都是把业务层隔离开了，据说是开发简便，易于测试。结果是最后一看，他们测试的都不是业务层。
不测试业务层，搞unit测试有什么意义。所谓解耦，首先是业务层不能依赖其他层次，其次是不同的业务概念之间不应该互相依赖。最终我们关心的是业务层，测试这个层次，才能保证系统可以迭代开发，满足变化的需求。
业务层的输入参数、输出参数和异常都应该是业务对象，这样就明确了代码的业务含义，这是业务层的任务。

本模式有个最大的缺陷，界面在进行业务方法调用时，经常需要获取业务方法的返回值，这种模式无法实现，因为Observer 模式中的Listener 无法提供返回值。
解决方案还在思考中，如果哪位网友有好的解决方法可以Share 一下。

lane_cn：哪些模式支持，可以列举一下吗？

业务层的测试应该由业务的单元测试去实现，而不应该由界面进行测试，我们虽然最关心业务层，但是界面的重要性也不能忽视。
如果由界面去触发业务层的测试，会使业务层的开发变得很被动，也不利于业务层的开发。
界面去触发业务层应该属于集成测试，可以在单元测试以后进行。

//1.业务方法的调用变成了字符串，而非直接调用
为什么不能用对象，如：
void onSaveOrUpdate(SaveOrUpdateEvent event)
／／2.业务方法的调用都是通过反射进行调用的，对开发阶段的调试也是比较复杂的。
更用不着了
／／３.本模式有个最大的缺陷，界面在进行业务方法调用时，经常需要获取业务方法的返回值，这种模式无法实现，因为Observer 模式中的Listener 无法提供返回值。
为什么不能设返回值？
Serializable performSaveOrUpdate(SaveOrUpdateEvent event)
而且没返回值也不一定代表不好测试啊．（虽然俺也不推荐mock工具）

只是随便举了hibernate里面的例子．．．
可能与楼主需求不同，还望谅解．