我知道我的 DDD 模型项目应该完全隔离，并且不引用我的应用程序的任何其他层，并且我的 WCF 服务将包含具有 WCF 服务所需的所有特殊属性的真实模型对象的 DTO 版本。该服务还将引用模型并知道如何在 DTO 和“真实”模型对象之间进行转换。
我想知道的是使用此服务的客户端应用程序是否应该使用 DTO 对象或真实模型对象与其通信？客户端应用程序是否应该负责将其从服务接收到的 DTO 对象转换为模型版本，还是应该将其构建到服务中以便客户端不直接处理 DTO 对象？
我正在考虑创建一个包装器类，它包装服务实例并公开相同的功能，但作为模型对象而不是 DTO 版本。好主意？馊主意？
WCF 不理解“真实模型类”，它只理解 DTO。客户端代码必须以一种或另一种方式理解这些 DTO（或序列化有效负载）。所以你的问题是你是否可以在客户端和服务器上使用相同的域模型类。
我正在考虑创建一个包装器类，它包装服务实例并公开相同的功能，但作为模型对象而不是 DTO 版本。好主意？馊主意？
这取决于您正在构建什么类型的应用程序以及您有什么部署限制。
直接从客户端和服务器引用域对象意味着您必须同时升级它们。例如，如果您的“用户”实体具有“名称”属性，并且您决定将其拆分为“第一”和“最后”，则需要同时更新客户端、服务器和数据存储。这只是一个简单的例子，模型行为的变化可能会带来更大的问题。如果您准备好在某些情况发生变化时重新部署整个堆栈，那么您的方法似乎没问题。在这种情况下，您甚至可以尝试避免使用“包装器”并尝试将此代码作为替代存储库实现。换句话说，您可以尝试使用两种存储库实现：一种用于客户端，一种用于服务。客户端存储库实现将使用 WCF 服务作为底层数据存储。
另一方面，最好将客户端与服务器上的更改隔离开来。在这种情况下，您的主域模型仅由服务引用，并作为特定于客户端的 DTO 向客户端公开。通过这种方式，您可以在不影响客户端的情况下自由地发展您的域模型和服务代码。客户端可能会有自己的模型类版本，如果你愿意的话，“子模型”，它将根据从服务器接收到的 DTO 进行填充。