领域驱动设计：这有点过分吗？

Question

我有一个使用Entity Developer生成的域。这将创建我的所有实体和我的数据库表。我使用NHibernate来填充通过存储库公开的实体。然后我有一个服务层，将存储库聚合成有用的服务。该层以两种方式使用。一，我使用服务作为我与Web层之间唯一的通信方式，我希望有一天能够使用WCF服务。现在，我正在开发我的网络层，我正在努力找出与我的服务进行通信的最佳方式。我的服务目前正在返回实体。我的网络层通过控制器中的服务抓取这些实体。这可能不是很干/ DDD。我假设我的服务层需要通过DTO进行接口。 DTO对我的WCF服务来说是完美的。至于我的Web层，我假设我将从服务层返回DTO，我想将它们映射到View Models（我使用的是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（或其他绑定）。考虑到这一点，应该以适配器无关的方式实现应用程序服务。这意味着没有WCF特定属性或数据协定。 WCF适配器又是应用程序服务的薄层。有些人可能会因为添加了分层而认为这种过度杀伤，但我发现它有益，因为它使应用层不受技术特定问题的影响。

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

请查看here，以便更深入地了解DDD中的服务。