只有真正地实践，才能很好地回答这些问题。于是，我开始结合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的框架架构设计的设计指南与最佳实践，这部分内容都是我在设计与实现Apworks框架的过程中，结合一些理论知识总结出来的，比如如何使用分离接口模式以减小框架本身与第三方组件之间的依赖，如何提高框架的可测试性等；这部分内容还将给出几个常用的设计模式、体系结构模式和语言惯用法的。NET（C#）实现，以便读者们在构建自己的应用程序开发框架时，可以在需要的时候直接引用本文给出的模式实现方式，提高开发效率。当然，这些内容都是我的经验总结，或许会因为我能力有限而出现疏漏或不合理的现象，这就需要读者朋友们给出意见给予指正了，我也会跟进这些反馈信息而不定期地修订原文。第二部分将以Apworks为例，详细讲解Apworks框架中某些组件的设计构想，例如，在设计外部事件存储（EventStore）的时候，我是如何考虑并实现存储机制的技术无关性的，又比如，“快照提供者（SnapshotProvider）”是如何支持可扩展的基于不同策略的快照功能实现机制，这些内容将在这部分进行讨论。

　　总之，本文将主要讨论基于。NET的应用程序框架架构设计实践，在此过程中会引用Apworks框架作为案例进行讲解，选用Apworks作为案例，首先是因为本文所讨论的所有内容都来源于该框架的设计与开发过程中，其次，Apworks已经是一个现成的框架了，读者朋友在学习的过程中可以有个成品作参考，以便更好地理解本文所讨论的内容。希望读者朋友不会误认为本文是Apworks的广告而对之产生反感，我真心希望本文能够给爱好企业级应用系统架构的朋友带来一定的参考价值。