DDD和客户端/服务器应用程序

Question

我想知道您是否有人在客户端/服务器应用程序中成功实施了DDD，并希望分享一些经验。

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

因此出现了一些问题：

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

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

Answer 1

1. 我不会直接将存储库暴露给客户端。您提到的第一个大问题是安全性：您无法信任客户端，因此您无法将您的数据访问API公开给潜在的恶意客户。
2. 使用服务在服务器上包装您的存储库，并在客户端中创建一个处理远程通信的瘦代理层。
3. 公开您的实体并不一定是一种不好的做法，只是当您开始考虑延迟加载，通过客户端不需要的线路发送数据等因素时会出现问题，等等。如果您编写DTO类，包装一个或多个实体和委托获取/设置调用，您实际上可以非常快速地构建DTO层，尤其是使用大多数IDE中可用的代码生成。

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

1. 客户端使用类似MVC，MVP或MVVM的东西来呈现UI。 Model层最终调用...

2. 我称之为“整合层”。这是客户端和服务器上存在的服务和数据对象的契约，以允许两者协调。通常，UI设计驱动该层，以便（A）仅将客户端需要的数据传递给它，并且（B）数据访问可以是粗粒度的，即“对该组所需的所有状态进行一个方法调用”。 UI。

3. 服务器使用它想要处理的业务逻辑和数据访问。这可能是DDD或者更古老的学校，比如使用DB中的存储过程构建的数据层以及许多“ResultSet”或“DataTable”对象。

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

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