DDD和Client/Server应用程序

Question

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

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

因此，出现了一些问题：

服务器应该向客户端公开存储库，还是需要有某种外观(能够处理instance)

• should的安全性--客户端实现存储库(以及一般的DDD )？)知道在客户机中，大多数逻辑都是与视图相关的和真实的业务逻辑驻留在服务器上。所有与服务器的通信都是异步进行的，我们在客户机上有一个单线程编程模型。

• 如何将客户端映射到服务器对象，反之亦然？我们尝试了DTO，但返回到公开对象的状态并直接映射到它们。我知道这被认为是错误的做法，但它为我们节省了难以置信的时间)--

总的来说，我认为随着Flex、Silverlight、JavaFX和我的发展，新一代的应用正在到来，我很好奇DDD是如何适应这一需求的。

Answer 1

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

。

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

1. 客户端使用MVC、MVP或MVVM来表示UI。模型层最终调用.
2. ，我可能称之为“集成层”。这是客户端和服务器上存在的服务和数据对象的契约，允许两者进行协调。通常，UI设计驱动这一层，因此(A)只有客户所需的数据才能传递给它，(B)数据访问可以粗粒度，即“对这组UI所需的所有状态进行一种方法调用。
3. Server使用它想要处理业务逻辑和数据访问的任何东西。这可能是DDD或其他更古老的方法，比如使用DB中存储的进程和许多"ResultSet”或"DataTable“对象构建的数据层。

。

关键是客户机和服务器都是非常不同的动物，它们需要独立地变化。为了做到这一点，您需要在UI的需求和服务器上可能需要的实际情况之间建立一个层，这是一个公平的折衷。

Silverlight/WPF和JavaFX相对于Flex +任何东西都有一个巨大的优势，那就是你可以在前两个版本中使用很多逻辑，因为应用程序的两边都有相同的VM。Flex是最好的UI技术，但是它缺少一个可以更有效地共享和重用代码的服务器组件。