概念中的ＤＤＤ
ＤＤＤ： 领域驱动设计，它是对面向对象的的分析和设计（ＯＯＡＤ，Object Orient Analysis Design）的一个补充，对技术框架进行了分层规划，同时对每个类进行了策略和类型划分。领域模型是领域驱动的核心 ，采用ＤＤＤ的设计思想，业务逻辑不再集中在几个大型的类上，而是在大量相对小的领域对象上，这些类具有自己的状态和行为，每个类都是完成的独立的，并与现实领域的业务对象形成一种映射。基于ＤＤＤ的架构设计，保证了系统的可维护性，扩展性和敏捷性，在处理复杂业务逻辑方面有着明显的优势！
编程世界观的改变
以下信息是从http://www.jdon.com/ddd.html上拷贝的，写的很好，这确实是一种编程世界观的改变，而传传统编程观念完全不同
过去需求分析和系统设计都是分离的，正如我们国家“系统分析师” 和“系统设计师” 两种职称考试一样，这样割裂的结果导致，需求分析的结果无法直接进行设计编程，而能够进行编程运行的代码却扭曲需求，导致客户运行软件后才发现很多功能不是自己想要的，而且软件不能快速跟随需求变化。
DDD则打破了这种隔阂，提出了领域模型概念，统一了分析和设计编程，使得软件能够更灵活快速跟随需求变化。
DDD革命性在于：领域模型准确反映了业务语言，而传统的分层架构只关心数据， 这些数据对象除了简单读、写操作外，没有任何业务方法，被比喻成失血模型，那么领域模型这种带有业务方法的充血模型到底好在哪里？
看到领域模型代码，就看到业务需求，没有翻译没有转换，保证软件真正实现“拷贝不走样”。
DDD最大的好处是：接触到需求第一步就是考虑领域模型，而不是将其切割成数据和行为，然后数据用数据库实现，行为使用服务实现，最后造成需求的首肢分离。DDD让你首先考虑的是业务语言，而不是数据。重点不同导致编程世界观不同。
ＤＤＤ的特点
- 分层架构
- 成熟，清晰的分层架构
- 领域对象与世界的业务映射
- 明确的职责划分
- 复用性
- 领域对象是核心
- 领域对象复用：完整的业务对象描述
- 设计利用：设计基于领域对象而非基于数据库的
- 适用场合
- 具备复杂业务逻辑的软件开发
- 对设计和开发人员要求较高
- 不适合普通的ＣＵＲＤ操作
- 系统的维护性与扩展性较高
对于ＤＤＤ系统架构的分层
不使用ＤＤＤ思想进行系统设计时，一般会分为３层，如数据层，业务层和表现层，而使用ＤＤＤ这后，分层的方式发生了一些改变，先来看一下
- 表现层：也叫ＷＥＢ层，ＵＩ层，一般体现出来的是页面的布局，可以用web mvc,web form,win form等去实现
- 应用层：用来协调应用活动，它不包含业务逻辑，它不保留业务对象的状态，但它保存应用任务的进度状态
- 领域层：包含领域信息，这是业务软件的核心，它保留业务对象的状态，对业务对象和它们状态的持久化工作委托给基础设施层
- 基础设施层：是其它层的基础，实现对业务对象的持久化，还对ＷＥＢ层可以引用本层
ＤＤＤ中的几个核心对象
Entities:这不是简单的poco实体，而是具备了业务逻辑的实体
Factories:工厂类，用来生产对象
Respositories:持久化,它本身就是DAO (Data Access Objects) 数据访问对象
Services：服务层，为上层提供了操作的接口，负责对象领域对象进行调试和封装，同时提供了各种形式的服务
ＯＫ，今天这讲先说到这里，只是概念，要求我们去理解它，事实上，这种理解确实有别于之前的架构思想，它是一种与传统方式截然不同的，需要我们用心去体会！
感谢您的阅读
相关文章
DDD~microsoft NLayerApp项目中的层次结构图
本文转自博客园张占岭（仓储大叔）的博客，原文链接：DDD~概念中的DDD，如需转载请自行联系原博主。
