.net - 领域驱动设计 : Is this overkill?

Question

我有一个使用 Entity Developer 生成的域。这将创建我所有的实体和我的数据库表。我使用 NHibernate 来填充通过存储库公开的我的实体。然后我有一个服务层，它将存储库聚合成有用的服务。该层有两种使用方式。第一，我使用服务作为与 Web 层之间的唯一通信方式，并且我希望有朝一日将这些服务用于 WCF。现在，我正在处理我的 web 层，我正在尝试找出与我的服务通信的最佳方式。我的服务目前正在返回实体。我的 Web 层通过 Controller 中的服务获取这些实体。这可能不是很 DRY/DDD。我假设我的服务层需要通过 DTO 进行接口(interface)。 DTO 非常适合我的 WCF 服务。至于我的 Web 层，我假设我会采用从我的服务层返回的 DTO，并且我想将它们映射到 View 模型(我使用的是 ASP.NET MVC 3)。

所以这就是我的架构最终的样子:

Domain
  Entities
  Repository Interfaces
Infrastructure
  NHibernate
  Concrete Repositories
Services
  DTO's
  Concrete Services
  Service Interfaces
  IIS hosted WCF
Website
  ViewModels

我会使用 Automapper 或 ValueInjecter 进行映射(可能是 ValueInjector，因为它能够展平和展平我的实体/DTO。

所以这是矫枉过正吗？我正在使用这种架构的系统非常大(我正在重写所有内容)。我做对了吗？一切都与 Ninject 解耦依赖，因为我可以看到想要随时更改系统的任何部分。任何想法、想法或批评都非常受欢迎和赞赏。

Answer 1

这是一种常见的架构，在实践中运行良好。一个核心优势是封装——您的域被服务层(DDD 中的应用程序服务)封装。

就 WCF 服务而言，我认为更适合它们的术语是适配器。这是基于 hexagonal architecture您的应用程序服务层是核心，WCF 将 HTTP(或其他绑定(bind))适应它。考虑到这一点，应用程序服务应该以与适配器无关的方式实现。这意味着没有 WCF 特定属性或数据协定。 WCF 适配器又是围绕应用程序服务的薄层。有些人可能会因为增加了分层而认为这种过度杀伤，但我发现它是有益的，因为它使应用程序层不受技术特定问题的影响。

这种架构是否矫枉过正取决于项目。回答这个问题的一种方法是确定应用程序是否主要是 CRUD，在这种情况下，DDD 是多余的，使用有助于从数据库读取并将数据直接作为服务公开的技术可能会更好。

看看here更深入地处理 DDD 中的服务。