DDD是告诉我们如何做好业务层！并以领域驱动设计思想来选择合适的框架。

我们知道软体的产生过程是分析、设计、编程、测试、部署。过去，分析领域和软体设计是分裂的，分析人员从领域中收集基本概念；而设计必须指明一组能在项目中适应编程工具构造的组件，这些组件必须能够在目标环境中有效执行，并能够正确解决应用程式出现的问题。 模型驱动设计(Model-Driven Design)抛弃了分裂分析模型与设计的做法，使用单一的模型来满足这两方面的要求。这就是领域模型。

DDD(Domain-DrivenDesign领域驱动设计)

2004年着名建模专家EricEvans发表了他最具影响力的着名书籍Domain-DrivenDesign–TacklingComplexityintheHeartofSoftware（中文译名领域驱动设计　2006年3月清华出版社译本，或称DomainDriven-Designarchitecture[EvansDDD]）。时值今日，DDD开发框架已经层出不穷（如RoR、RIFE、JdonFramework等），我们项目软体包结构都变成了这样xxx.model;xxx.service，DDD思想可以说是遍地开花了.领域建模是一种艺术的技术，不是数学的技术，它是用来解决複杂软体快速应付变化的解决之道.

模型驱动设计(Model-DrivenDesign)抛弃了分裂分析模型与设计的做法，使用单一的模型来满足这两方面的要求。这就是领域模型。单一的领域模型满足分析原型和软体设计，如果一个模型实现时不实用，重新寻找新模型。如果模型没有忠实表达领域关键概念时，也必须重新寻找新的模型。建模和设计成为单个叠代循环。将领域模型和设计紧密联繫。，建模专家必须懂设计，会编程。

根据Eric的理论，业务层将细分为两个层次套用层和领域层。套用层定义软体可以完成的工作，并且指挥具有丰富含义的领域对象来解决问题，保持精练；不包括业务规则或知识，无业务情况的状态；领域层负责表示业务概念、业务状态的信息和业务规则，是业务软体核心。层次之间必须清晰分离，每个层都是内聚的，并且只依赖它的下层.

Eric特别指出那种将业务逻辑交由业务界面处理的快速UI方式是旁门左道。希望象C/S结构那样可视化拖拖图形就完成的软体开发是一种错误的方向，开发时快速，难于维护和扩展，虽然使用J2EE技术，其实是一种伪多层技术。建议购买"领域驱动设计"这本译书学习下.

在领域对象的生命周期中,有三个模式来维护对象的完整性聚合（Aggregate）定义清晰的所有权和边界使模型更加紧凑，避免出现盘根错节的对象关係网；工厂（Factory）和仓储（Respository）。当一个对象生命周期之始，使用工厂和仓储提供访问和控制模型对象的方法。建立聚合的模型，并把工厂和仓储加入到设计中来，可以使我们系统地对模型对象进行管理。聚合圈定出一个範围，在这个範围中，对象无论在哪个生命周期，保持不变性。

MF（MartinFowler）曾经提出有名的贫血模型或充血模型，他认为实体模型对象中只有弱行为setter和getter方法，没有真正行为，好像缺少血液的人，不和谐了，而Eric认为，在DDD中，领域中的一些概念是不能作为模型中的对象来处理的，如果将这些功能概念强行加给实体对象和值对象，会破坏模型中对象的定义.我们的DDD项目中都是以充血模型存在着，所以，Eric呼唤建模专家必须懂得实现，懂得软体技术。