构打交道，但如果设计在基础结构层，由于仓储是直接对领域对象进行操作的，那么

从.NET 的开发上来看，基础结构层的程序集就必须引用领域模型的程序集，于是，领域
模型就无法去引用基础结构层的程序集，因为会产生循环引用，因此也就无法去使用基

础结构层的服务了，像这样的问题又如何解决?在领域模型中，领域对象能直接操作仓储
来完成业务逻辑吗?应用层的作用是任务协调，而任务又包含哪些内容?协调又是怎样的
一个过程?应用层与用户界面层通信是通过数据传输对象(DataTransferObject，DTO)
实现的，那么是否需要为每一个领域对象设计一个 DTO，如果是的话，那岂不是开发过
程会变得非常繁杂，而且会降低应用程序的可维护性，比如今后如果领域模型发生了更

改，那么也需要相应地更改 DTO。更进一步，是否在领域层与基础结构层的数据访问组
件之间也需要引入类似 DTO 的概念，以便解耦领域模型与数据模型?但如果的确如此的
话，那系统中岂不是充斥着各种各样的数据对象?这是基于领域驱动设计的软件架构的最
佳实践吗?

　　只有真正地实践，才能很好地回答这些问题。于是，我开始结合

ADO.NETEntityFramework 来实践领域驱动的软件架构，并结合自己的收获总结了

《EntityFramework 之领域驱动设计实践》系列文章，发表在了博客园上。该系列文章
获得了博客园社区读者的广泛关注，很多朋友纷纷参与讨论，并提出了不少针对性很强

的问题，我也尽我自己的最大努力，尽量做到有问必答，于是通过反反复复的讨论与相

关知识的慢慢积累，一种面向领域驱动的软件架构设计方式已经在我脑海里成型了，并

“

”

且在实践过程中，自己总结了一些 哪些方式是可行的、哪些方法是不合理的 基于领域

驱动的软件架构设计最佳实践。

　　之后，我开始着手把我所总结的这些内容实现在一个应用程序开发框架上，使得软

件人员能够非常方便快捷地开发出基于领域驱动的软件架构的应用程序。我将这个框架

取名为 Apworks(ApplicationDevelopmentFrameworkandTools 的缩写，取名其实也
是来源于我之前提到的那个未完成的框架名称)。在 2009 年底到 2010 年初，我在微软
的开源网站 codeplex 上签入了 Apworks 的第一份代码，而在 2010 年底，成功完成了

Apworks 的 Alpha 版本，与此同时，ApworksAlpha 版的第一个演示案例

TinyLibraryCQRS(tlibcqrs)也在 codeplex 上发布，社区不少朋友对 Apworks 以及

tlibcqrs 都非常关注，有朋友甚至希望能够将 Apworks 整合到他们的项目中，在此，我

对这些朋友们的支持表示衷心感谢。

　　基于.NET

“

”

的框架的设计与开发更不是一件容易的事情，这与 领域驱动设计 相比，

它又属于另一个领域：我们需要考虑的不是通用语言，不是 4+1 视图，不是用例，不是
角色，不是 DCI，不是领域建模;我们需要考虑的是如何搭建一个高效的、稳定的、安全
的、可扩展的、基于.NET 的应用程序开发框架。而这些，就是本文所要重点讨论的内容。

　　本文将分为两大部分，第一部分重点讨论基于.NET 的框架架构设计的设计指南与最