我想知道你们中是否有人在Client / Server应用程序中成功实现了DDD并想分享一些经验.

我们目前正在开发Flex中的智能客户端和Java中的后端.在服务器上,我们有一个向客户端公开的服务层,它在一些其他服务方法中提供CRUD操作.据我所知,在DDD中,这些服务应该是存储库,服务应该用于处理不适合存储库的用例.现在,我们在接口后面的客户端上模仿这些服务,并通过IoC容器注入实现(Webservices,RMI等).

所以出现了一些问题：

>服务器是否应该将存储库暴露给客户端,或者我们是否需要某种外观(例如能够处理安全性)
>客户端应该实现存储库(以及一般的DDD吗？)知道在客户端中,大多数逻辑与视图相关,并且实际业务逻辑存在于服务器上.与服务器的所有通信都是异步发生的,我们在客户端上有一个单线程编程模型.
>如何将客户端映射到服务器对象,反之亦然？我们尝试了DTO,但又恢复了暴露对象状态并直接映射到它们.我知道这被认为是不好的做法,但它为我们节省了不可思议的时间)

总的来说,我认为随着Flex,Silverlight,JavaFX的发展,新一代应用程序随之而来,我很好奇DDD如何适应这一点.

最佳答案 >我不会直接将存储库暴露给客户端.您提到的第一个大问题是安全性：您无法信任客户端,因此您无法将您的数据访问API公开给潜在的恶意客户端.

>使用服务在服务器上包装您的存储库,并在客户端中创建一个处理远程通信的瘦委托层.

>暴露你的实体并不一定是一种不好的做法,只是当你开始考虑延迟加载,通过客户端不需要的线路发送数据等因素时会出现问题,等等.如果你写了一个包装了一个的DTO类或者更多实体和委托获取/设置调用,您实际上可以非常快速地构建DTO层,尤其是使用大多数IDE中可用的代码生成.

所有这一切的关键是一组模式应该只适用于您的应用程序的一部分,而不是整个应用程序.您在域模型中拥有丰富的逻辑并使用存储库作为DDD的一部分进行数据访问这一事实不应以任何方式影响客户端.从概念上讲,我构建的RIA有三层：

>客户端使用类似MVC,MVP或MVVM的东西来呈现UI. Model层最终调用了……
>我可以称之为“整合层”.这是客户端和服务器上存在的服务和数据对象的契约,以允许两者协调.通常,UI设计驱动该层,以便(A)仅将客户端需要的数据传递给它,并且(B)数据访问可以是粗粒度的,即“对该组所需的所有状态进行一个方法调用”. UI.
>服务器使用它想要处理的业务逻辑和数据访问.这可能是DDD或者更旧的学校,比如使用DB中的存储过程和许多“ResultSet”或“DataTable”对象构建的数据层.

关键在于客户端和服务器都是非常不同的动物,它们需要独立变化.为了做到这一点,你需要一个介于两者之间的层,这是UI的需求和服务器上可能需要的事实的公平妥协.

Silverlight / WPF和JavaFX优于Flex的一大优势是,您可以在前两个中使用大量逻辑,因为您在应用程序的两侧都有相同的VM. Flex是最好的UI技术,但缺少服务器组件,可以更有效地共享和重用代码.