【IT168 应用】我研究领域驱动设计已经近4年时间了，在这4年里，我从了解领域驱动设计的基本思想开始，系统地学习了与领域驱动设计相关的概念、开发模式以及应用系统架构风格，并将其运用在了实际的项目架构与开发中。在此之前，我一直被一些应用程序架构设计上的问题所困扰，比如：在数据持久层，如何让数据持久化机制能够支持不同的数据库类型，甚至是非关系型数据库;如何能够让开发人员将关注点放在领域模型上，而在更改领域模型的同时，不用去关心数据持久化的细节内容;如何将应用程序的视图模型部署在服务器端，而客户端可以通过不同的用户界面代理产生不同的视图展示机制，等等。为了实现设计思想，我于2008年开发了一套基于类似XUP协议的应用框架原型，在客户端通过WCF技术与服务器进行通信，以支持服务端事件的响应与处理，而数据访问部分则采用NHibernate的Schema Tools，在服务每次启动的时候比对领域模型与数据库的差异从而动态调整数据库结构。整个系统的运行机制有点类似ASP.NET，但它可以支持诸如Windows Forms、WPF等多种用户界面机制(如图一)。在完成了第一阶段的原型开发后，我在《计算机工程与应用》期刊上发表了一篇题为《基于XML的松耦合UI架构的设计与实现》的论文，阐述了这个应用框架的设计与开发的要点与细节。

　　遗憾的是，我并没有真正地完成这个框架的开发。首先，在基础结构层，使用NHibernate的Schema Tools来完成数据库的同步过程，会产生很多限制，比如：自动化的数据库结构变更会出现很多冗余信息，数据库必须采用关系型数据库，框架本身需要依赖于一套特定的机制才能实现其功能，ORM具有一定程度的性能损耗，于是应用程序就会产生性能调优的瓶颈;其次，没有对领域模型的设计与开发做出很好的支持，整个框架更多地是在技术层面为应用程序的开发提供便捷，忽视了领域模型的重要性，这就使得整个框架没有一个清晰的思路去解决数据映射与传输方面的问题;再次，虽然框架已经实现了基于XML的界面描述、事件绑定、事件桩与事件路由等基本特性，但与成熟的框架相比，还是有很大的差距，而弥补这样的差距还需要花费很大的努力，比如：资源管理系统、基于角色的权限管理系统、商业许可证的授权方式与支持系统、报表管理系统、基于LUA或Javascript的客户端事件处理系统等等，而这所有的内容都不是光靠我一个人所能完成的。总之，从技术架构上看，除了能够支持多种用户界面机制外，整个框架跟ASP.NET很相似。

　　然而在设计与实现这个框架原型的过程中，我思考了很多，也学到很多。随着领域驱动设计思想的引入，我慢慢地在思考：领域模型能否以DTO的形态出现在应用层?仓储是领域概念，但如果真正将其实现在领域层则明显不合适，因为它需要与外部技术架构打交道，但如果设计在基础结构层，由于仓储是直接对领域对象进行操作的，那么从.NET的开发上来看，基础结构层的程序集就必须引用领域模型的程序集，于是，领域模型就无法去引用基础结构层的程序集，因为会产生循环引用，因此也就无法去使用基础结构层的服务了，像这样的问题又如何解决?在领域模型中，领域对象能直接操作仓储来完成业务逻辑吗?应用层的作用是任务协调，而任务又包含哪些内容?协调又是怎样的一个过程?应用层与用户界面层通信是通过数据传输对象(Data Transfer Object，DTO)实现的，那么是否需要为每一个领域对象设计一个DTO，如果是的话，那岂不是开发过程会变得非常繁杂，而且会降低应用程序的可维护性，比如今后如果领域模型发生了更改，那么也需要相应地更改DTO。更进一步，是否在领域层与基础结构层的数据访问组件之间也需要引入类似DTO的概念，以便解耦领域模型与数据模型?但如果的确如此的话，那系统中岂不是充斥着各种各样的数据对象?这是基于领域驱动设计的软件架构的非常好的实践吗?

　　只有真正地实践，才能很好地回答这些问题。于是，我开始结合ADO.NET Entity Framework来实践领域驱动的软件架构，并结合自己的收获总结了《Entity Framework之领域驱动设计实践》系列文章，发表在了博客园上。该系列文章获得了博客园社区读者的广泛关注，很多朋友纷纷参与讨论，并提出了不少针对性很强的问题，我也尽我自己的最大努力，尽量做到有问必答，于是通过反反复复的讨论与相关知识的慢慢积累，一种面向领域驱动的软件架构设计方式已经在我脑海里成型了，并且在实践过程中，自己总结了一些“哪些方式是可行的、哪些方法是不合理的”基于领域驱动的软件架构设计非常好的实践。