从 WCF 服务访问领域驱动设计类库

Question

我需要一些帮助来阐明我应该如何设置我的项目。我的解决方案结构如下：

Company.DataTransferObjects
--AdminDTO.cs
--CustomerDTO.cs
Company.DataTransferObjects.Helpers
Company.Infrastructure.DomainServices
--Admin
---AdminService.cs
--Customer
--CustomerService.cs
Comapny.Infrastructure.Repositories
--Admin
---AdminRepository.cs
--Customer
---CustomerRepository.cs
Company.Domain
--Admin
---Admin.cs
---IAdminRepository.cs
--Customer
---Customer.cs
---ICustomerRepository.cs
Company.WebServices
--WebApi.cs
--IWebAPI.cs

我的问题如下：

1) 你觉得我的设置合适吗？

2) DTO。从 Web 服务的角度来看，应该在哪里创建 DTO？ 我应该在独立的类库中创建 DTO 并引用 它们来自 WebService 还是应该成为我的 Web 服务项目的一部分？

另外，我不清楚我的 DTO 应该如何与我的域对象交互。 有人可以从程序流程的角度解释他们的目的，特别是，如果您正在创建 WCF 服务，您将如何操作它们？

3) 域服务。我仍然很难将注意力集中在域服务的目的上。这是否暴露了未触及数据库并且需要无法直接访问的存储库方法的操作功能？ 换句话说，域服务是一种操作多个存储库方法的方法吗？因此，如果我的 WCF 服务正在调用可以通过存储库方法访问的数据，那么它应该这样做。但是，如果它需要多个存储库方法的结果数据，那么这应该通过域服务来完成吗？

4) 外观模式在 DDD 架构中适合什么位置？

请原谅我的困惑，我正在努力理解。如果您能告诉我应该从我的 WCF 服务访问“什么”，那将是一个很大的帮助。

谢谢！

Answer 1

按相反的顺序回答您的问题：

4) 您的网络服务实际上是您的域的门面。

3) 域服务也可以访问数据库，它们通常是消费代码应该用来与您的域就涉及多个实体的任何事物或代表一系列事务步骤的事物进行对话的主要 API .有些人认为存储库是域服务的特例（而不是非此即彼）。我通常认为我的服务是我域的公共接口。

2) 当您（或计划最终）跨越物理边界时，DTO 通常很有用。任何时候你认为你可能需要序列化一些东西（例如变成一个 SOAP 消息），你想要考虑一个 DTO。因此，在您的情况下，您的 WCF 项目将使用 DTO 作为其 DataContracts，但在内部它可能使用您的域对象（除非您希望您的域位于不同的应用程序域或不同的物理框上）。

1) 纯属个人喜好；你的布局看起来并没有不合理，虽然它与我通常的组织方式不同。