标签：
要研究DDD，必须认清DDD的核心是通用语言和模型驱动设计。即使是DDDLite（技术上的DDD），也必须清楚DDD在架构中的位置和必须的架构知识，否则一路跑到哪里能否回来都是未知了。我们先了解常用架构分层，再了解DDD的所在层次和范畴，然后强调DDD的核心。包括从架构到领域模型设计方面的决策和自己的些许实践。
1.三层作为基础：表示层、业务逻辑层、数据访问层是所有讨论的基础。有2个最重要的决策和实践等待你应用和发现：
（1）在假设存在多个表示层的基础上，你可以据此将分散在表示层中的业务逻辑代码从其中分离。
（2）在假设需要支持不同种数据源的的基础上，你可以将分散在业务逻辑层的数据访问层代码从其中分离出来。
这意味着大多数情况你不用冥思苦想、搜肠刮肚的去搞明白到底什么是三层，如果你书读的多，可以从书中看到这些原则；如果你代码写的多又习惯重构你会自然发现这些原则。发现和在重构中应用这些原则是最重要的，完全不可能存在【努力太少，想的太多】的方式搞清这些。
2.四层作为核心：将业务逻辑层分离为应用层和领域层是领域驱动设计的架构方面的核心。同样有2个最重要的决策和实践来保持领域层的纯粹：
（1）将表示层必须的业务逻辑调用以应用接口的方式分离到应用层。其他无需公开的部分分离到领域逻辑层。
（2）将业务逻辑对具体技术的依赖转换为接口依赖，将接口的定义和调用分离到应用层中。
这意味着即使不考虑领域模型的组织形式，我们也可以将应用层和领域层大体上理清。你需要动手，只看是不行的。大多数问题都经不住实践，重构后大多数问题实际上都不存在，你会总结出这些实践，但是你的代码也不会完整的反应出这些原则，那是因为这本身就是架构层次上的决策，没有任何框架和演示能将架构上决策的东西完美体现出来。完全不可能存在【只看代码】的方式搞清这些。
3.领域模型的组织形式：实体、值对象和领域服务只是领域模型的一种组织形式。必须注意2点：
（1）领域模型的组织形式是领域层的范畴。
（2）是否采取经典DDD领域模型的组织方式对架构层次没有影响。
这里终于到了领域驱动设计相关的概念了，之前讨论都是的架构方面的，可以说是无关领域驱动的。领域驱动设计的核心是什么？设计是一个过程，领域驱动是一个原则。在领域驱动的原则下进行设计，设计的结果是一系列主要在领域层范畴的模型。如果自己总结不出来，可以去看经典DDD的附录领域驱动设计关系图的人都知道的两个核心：通用语言和模型驱动设计。因此谈论DDD必须要结合具体的领域逻辑和设计中的各种决策以及结果，即使是DDDLite（技术角度的DDD）也不应该因为领域驱动设计中涉及到了很多架构方面的概念就认为这些概念属于领域驱动设计。至少应该清楚DDD的架构无关性。
4.领域模型的结果：
（1）建模的结果由领域逻辑决定，结果包含一种或多种类型（实体、值对象和领域服务）的一个或多个模型。
（2）如果领域逻辑只是简单计算过程，那么模型可能只是包含一个方法的一个领域服务。
（3）如果领域逻辑偏向数据管理，模型可能主要由一系列关联的实体组成，这些实体的形式上和贫血模型一致。
由于大多数的应用程序的领域逻辑都比较简单，偏向过程和数据操作，因此领域模型显得不够丰富，但这都是领域逻辑自然分析得到的结果。在不断的重构中，实体和领域服务会逐渐的将应用层中的领域逻辑代码分离出来。
5.实体：
（1）如果业务逻辑用过程表达更适合，实体没必要存在。
（2）实体对应集合和类型的概念，同种实体的多个对象都是唯一的。因此论坛领域（板块、主题、评论）和电商领域（分类、产品、订单）这些都是自然而然的实体类型。
6.值对象：
（1）如果实体比较简单，值对象没必要存在。
（2）值对象对于枚举和状态的概念。值对象作为实体属性的一部分。这些值对象本质上是没有任何差别的。因此论坛领域（主题状态）和电商领域（交易类型、订单状态）这些都是自然而然的值对象。
7.领域服务：
（1）如果实体的方法可以修改为静态方法，那么这个方法更适合置于领域服务中。
（2）如果我只对领域层进行单元测试，必须反复写一些出现在应用层的代码来协调领域逻辑，那么这些代码很可能属于领域服务。
8.总结：
（1）在应用DDD之前至少要达到能够正确的认识三层。如果这点都达不到，不可能成功应用。大体上代码都不知道写哪里，还谈什么分离领域。
（2）前期必须在架构和建模方面尽量做到层次分明和概念清晰，后期边重构边添加功能比不重构添加功能更快，最怕的是认识不上去而不是没有解决方案。
（3）不是必须掌握所有的DDD知识和概念才能应用DDD。DDD的核心是通用语言和模型驱动设计。
（4）DDD是一个过程，这个过程在不断的重构中得到最适合的设计和代码，因此不要为了DDD而DDD。
顺便推荐以下ASP.NET设计模式这本书，这本书和作者之前的一些书及其源代码是这些年国内各大博客论坛的99%的所谓各种框架和原创文章和出版图书的来源。作者的成功在于类似科普的手法让大家把模式和代码直接展示给大家，失败的是国内万年不变的抄袭风格依然没有放过这本书，大把大把二次加工出各种文章、帖子、讨论和图书。但这不是作者和其作品的失败，而是我们这些披着原创的帽子的抄袭者的悲哀。架构方面的知识，本身必须有多个项目经验的实践才能有切实的优缺点体会和认知，DDD更是必须有复杂业务逻辑方面的逐渐重构经验才能有所积累和体验。要想有所进步，处处离不开思考和重构。在国内这种技术社区的气氛下，实践类的不被推崇，伪技术文（标题党+图片党+程序人生党）和伪原创（抄袭国外图书、博客特意声明为原创的）大行其道，如果你看了好几年博客觉得没看到有用的文章，或操作性不强或根本无法推敲，静下心来，开始订阅有用的博客（我关注的博客都建议你看看），开始阅读国外的技术书籍和博客，开始重构你的代码，收获会日积月累。
标签：
原文地址：http://www.cnblogs.com/easygame/p/4458184.html
