.net 领域驱动设计：这是不是太过分了？

我有一个使用EntityDeveloper生成的域。这将创建我的所有实体和数据库表。我使用NHibernate填充通过存储库公开的实体。然后我有一个服务层，它将存储库聚合成有用的服务。该层有两种使用方式。第一，我使用服务作为与我的web层进行通信的唯一手段，我希望有一天能将这些服务用于WCF。现在，我正在研究我的web层，我正在尝试找出与我的服务进行通信的最佳方式。我的服务当前正在返回实体。我的web层通过控制器中的服务抓取这些实体。这可能不是很干燥/DDD。我假设我的服务层需要通过DTO接口。DTO对于我的WCF服务来说是完美的。至于我的Web层，我假设我将使用从服务层返回的DTO，并且我希望将这些DTO映射到视图模型（我使用的是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或ValueInjector来进行映射（可能是ValueInjector，因为它能够展平和取消展平我的实体/DTO）

---

这是不是太过分了？我使用的这个架构的系统相当大（我正在重写所有内容）。我做得对吗？Ninject的每一项功能都与依赖性分离，因为我可以看到希望随时更改系统的任何部分。任何想法、想法或批评都是非常受欢迎和赞赏的。

这是一种常见的体系结构，在实践中运行良好。一个主要好处是封装—您的领域就是封装由服务层（DDD中的应用程序服务）创建

就WCF服务而言，我认为对它们来说更合适的术语是适配器。这是基于应用程序服务层处于核心的位置，而WCF适应HTTP（或其他绑定）考虑到这一点，应用服务应该以一种不可知的方式实现。这意味着没有WCF特定属性或数据契约。WCF适配器又是应用服务周围的一层薄薄的层。有些人可能认为这是由于增加的分层而造成的，但我发现它是有益的，因为它保持了应用程序。无技术特定问题的层

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

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

引用自：伟大的程序员有能力进行熟练/快速/肮脏的黑客攻击和优雅/精致/健壮的解决方案，并有智慧选择适合给定问题的解决方案。一些较小的程序员似乎缺乏对必要细节的极度关注对于一些问题，另一些则陷入了完美主义模式。