写在前面
也许在阅读了上篇文章中我列出的那部分资料后，还是有很多朋友对领域驱动设计不了解。正如上文评论中有网友提到微软西班牙团队也做了一个面向领域的分布式应用系统架构的案例，地址是http://microsoftnlayerapp.codeplex.com/。在这个站点的首页上，又对领域驱动设计做了诠释，我觉得总结的很好，特地将其翻译成中文写在这里，供大家参考：
|
DDD is much more than this!
We‘re talking about complex apps…, all their business rules (Domain logic) are points that, in most of the cases, need to be changed quite a lot during the app’s life. So it is critical to be able to change the app and test it in an easy way and independently
from infrastructure areas (technology, data stores, data access technolgies, ORMs, etc.). Because of that, it is important to have the Domain/Business Layer (domain logic, entities, etc.) decoupled from the other layers. DDD - 不仅仅是这些 我们讨论的是复杂的应用系统……，通过这些应用系统的业务规则（领域逻辑）我们可以了解到，在大多数情况下，在应用系统的整个生命周期里，业务规则是可变的一部分。因此，能够很方便地对应用系统进行变更并测试，并使其独立于基础结构层设施（比如：技术、数据存储、数据访问技术、ORM等等），就显得非常重要。正因为如此，我们很有必要将领域/业务层（领域逻辑、实体等等）从其它分层中解耦出来。 话虽如此，根据我们的建议，能够适应上述需求的架构风格就是面向领域的多层架构，但它仅仅是领域驱动设计（DDD）的一个部分。本案例展示了实现面向领域的多层架构的一种方式。但需要注意的，而且非常重要的是，DDD不仅仅只是架构+模式。DDD是开发应用程序的一种方式，是团队在项目中工作的一种方式。根据DDD，项目团队需要以一种特殊的方式进行合作，应该能够直接与领域专家（通常就是客户）进行沟通。整个团队需要使用“通用语言”这一能够被所有人接受的语言，等等。然而，本案例没有包含这些内容，因为这是一种“过程”，一种ALM。所以，如果你真的希望100%实践DDD，你需要阅读Eric Evans写的《领域驱动设计-软件核心复杂性应对之道》一书，或者其它的一些讨论DDD过程的书籍，这些书籍会对DDD过程、项目和团队做比较详细的介绍，而不仅仅是谈论架构和模式。架构和模式仅仅是DDD中很小的一部分，而我们在这里展示的就恰好是这一部分。总之，我们必须强调，DDD不仅仅是架构+模式。 |
很多网友对什么是DDD有很大争议，我想，看了上面的文字，问题应该大致清楚了。也在此借用这段文字，说明我研究学习DDD实践的意图。言归正传，本文将对Tiny Library CQRS（简称tlibcqrs，下同）的解决方案结构和系统架构做个简要的介绍。
Tiny Library CQRS解决方案结构
从Solution Explorer上可以看到，tlibcqrs包含9个项目，依次为：
仍然说明一下，本案例没有加入太多的cross-cutting基础结构层设施，因此，诸如日志、缓存、异常处理都很弱甚至没有，朋友们不要觉得好奇，这只是一个演示，为了节约时间，我忽略了这部分内容。今后我会将其补上。
系统架构
tlibcqrs的系统架构就是经典的CQRS架构，之前在我的《EntityFramework之领域驱动设计实践【扩展阅读】：CQRS体系结构模式》一文中，我已经给出了整个系统的结构简图，在此再一次贴出来，以表示tlibcqrs的系统架构。
为了让大家看tlibcqrs源代码方便，在此特地以“创建读者”为例，将sequence描述一下。
大致可以用下面的UML Sequence Diagram描述这一过程【请单击此处下载XPS文件以查看大图】：
下一讲，我会介绍一些tlibcqrs中的一些新思想，至于CQRS框架的设计，我会在另外的系列文章中详述。
CQRS体系结构模式实践案例【Tiny Library系统架构】
原文：http://blog.csdn.net/zhixiang2010/article/details/18790331