隔离的领域层

如果是为了表现层和业务逻辑层的解耦，那么只要做到Code to interface就够了。做表现层的单元测试时，用Mock代替业务逻辑层也不麻烦啊。

如果是为了在多客户端之间做数据同步，那么就考虑Observer和Command模式。

把业务操作抽象成Event可能不太直观，抽象成Command比较容易理解。

//把业务操作抽象成Event可能不太直观，抽象成Command比较容易理解

Event和Command本质上是相似的，都是发一个Event(Action)出去,完成一系列的事情．反正对于前台就是这么个表象．

俺有次做个类似的项目(不同cms系统的文件导入问题），名字不知道用Command还是用stategy,最后干脆就用action，看着还蛮舒服．呵呵．

我认为用Command 不是很合适，因为DomainEvent 不仅仅是从UI 层发向Domain 层，Domain 层也可以发送其它客户端产生的Domain 事件。
如果使用Command，好像只是从UI 层发向Domain 层的命令，不够全面。
大家还有其它意见吗？

我以前就是这样做的，UI把Command给Server，Server再把Command转给其他客户，只是Command在不同的地方有不同的执行逻辑。不同的接收者接到同一个Command作出不同的反应，这也很自然。

另外，如果UI给Server的数据和Server给其他客户端的数据有很大不同的话，那么也可以考虑UI给Server Command, Server再给其它客户端Event，Command和Event可以是完全不同的对象。当然，这个要视应用的具体情况来定。

合理的隐喻对于理解系统架构，有时还是很重要的。

如果UI层给Domain层的是Commnad，而Domain 层给UI 层的是Event，那么我的DomainBinder 就没有什么意义了。它们肯定是一种类型。

Command 代表着主动发起的含义，Domain 层发给UI层时使用Command 肯定不合适。UI 层发给Domain 层使用Commnad 还可以接受，我再想想

如果UI层给Domain层的是Commnad，而Domain 层给UI 层的是Event，那么我的DomainBinder 就没有什么意义了。它们肯定是一种类型。

Command 代表着主动发起的含义，Domain 层发给UI层时使用Command 肯定不合适。UI 层发给Domain 层使用Commnad 还可以接受，我再想想

软件设计是一件很自然的事情，大部分情况都可以用常识来解决，不要搞得太别扭。
要说模式，软件所有的模式都可以归结到一个模式上：层次模式。
老老实实的把业务层写出来，把业务对象原原本本的造出来，比一大堆花哨的模式有效多了。
软件的价值在于实现业务流程的自动化，需求的变更也都是从业务层开始的。业务的复杂度是软件必然无法逃避的。

看了半天没看明白。
正如BirdGu所说，在service接口后面提供mock，不就隔离了领域层了么？

如果使用Mock，那就不应该称为隔离了。
我的目的是UI 层和Domain 层没有直接的方法调用。