DDD(二,三,四)【概念中的DDD】【microsoft NLayerApp项目中的层次结构图】【充血模型和失血模型】

概念中的ＤＤＤ

ＤＤＤ：　领域驱动设计，它是对面向对象的的分析和设计（ＯＯＡＤ，Object Orient Analysis Design）的一个补充，对技术框架进行了分层规划，同时对每个类进行了策略和类型划分。领域模型是领域驱动的核心　，采用ＤＤＤ的设计思想，业务逻辑不再集中在几个大型的类上，而是在大量相对小的领域对象上，这些类具有自己的状态和行为，每个类都是完成的独立的，并与现实领域的业务对象形成一种映射。基于ＤＤＤ的架构设计，保证了系统的可维护性，扩展性和敏捷性，在处理复杂业务逻辑方面有着明显的优势！

编程世界观的改变

以下信息是从http://www.jdon.com/ddd.html上拷贝的，写的很好，这确实是一种编程世界观的改变，而传传统编程观念完全不同

过去需求分析和系统设计都是分离的，正如我们国家“系统分析师” 和“系统设计师” 两种职称考试一样，这样割裂的结果导致，需求分析的结果无法直接进行设计编程，而能够进行编程运行的代码却扭曲需求，导致客户运行软件后才发现很多功能不是自己想要的，而且软件不能快速跟随需求变化。

DDD则打破了这种隔阂，提出了领域模型概念，统一了分析和设计编程，使得软件能够更灵活快速跟随需求变化。

DDD革命性在于：领域模型准确反映了业务语言，而传统的分层架构只关心数据， 这些数据对象除了简单读、写操作外，没有任何业务方法，被比喻成失血模型，那么领域模型这种带有业务方法的充血模型到底好在哪里？

看到领域模型代码，就看到业务需求，没有翻译没有转换，保证软件真正实现“拷贝不走样”。

DDD最大的好处是：接触到需求第一步就是考虑领域模型，而不是将其切割成数据和行为，然后数据用数据库实现，行为使用服务实现，最后造成需求的首肢分离。DDD让你首先考虑的是业务语言，而不是数据。重点不同导致编程世界观不同。

ＤＤＤ的特点

分层架构

1. 成熟，清晰的分层架构
2. 领域对象与世界的业务映射
3. 明确的职责划分

---

复用性

1. 领域对象是核心
2. 领域对象复用：完整的业务对象描述
3. 设计利用：设计基于领域对象而非基于数据库的

---

适用场合

1. 具备复杂业务逻辑的软件开发
2. 对设计和开发人员要求较高
3. 不适合普通的ＣＵＲＤ操作
4. 系统的维护性与扩展性较高

对于ＤＤＤ系统架构的分层

不使用ＤＤＤ思想进行系统设计时，一般会分为３层，如数据层，业务层和表现层，而使用ＤＤＤ这后，分层的方式发生了一些改变，先来看一下

1. 表现层：也叫ＷＥＢ层，ＵＩ层，一般体现出来的是页面的布局，可以用web mvc,web form,win form等去实现
2. 应用层：用来协调应用活动，它不包含业务逻辑，它不保留业务对象的状态，但它保存应用任务的进度状态
3. 领域层：包含领域信息，这是业务软件的核心，它保留业务对象的状态，对业务对象和它们状态的持久化工作委托给基础设施层
4. 基础设施层：是其它层的基础，实现对业务对象的持久化，还对ＷＥＢ层可以引用本层

ＤＤＤ中的几个核心对象

Entities:这不是简单的poco实体，而是具备了业务逻辑的实体

Factories:工厂类，用来生产对象

Respositories:持久化,它本身就是DAO (Data Access Objects) 数据访问对象

Services：服务层，为上层提供了操作的接口，负责对象领域对象进行调试和封装，同时提供了各种形式的服务

ＯＫ，今天这讲先说到这里，只是概念，要求我们去理解它，事实上，这种理解确实有别于之前的架构思想，它是一种与传统方式截然不同的，需要我们用心去体会！

---

DDD~microsoft NLayerApp项目中的层次结构图

如果你想学好一样东西，一定要看高手是如何做的

如果你想学好.net，一定要看.net framworks源代码

如果你想学好分层结构，一定要去看petshop项目

如果你想学好MVC，一定要去看dinner项目

如果你想学好DDD，一定要去看Microsoft NLayerApp项目

呵呵，今天主题是ＤＤＤ，所以，我们主要看一下NLayerApp的项目结构，在微软架构师开发一个项目时，他的心中一定对自己系统的架构很清晰，这时，他会使用一定工具把它的思想写出来，以便更好的让开发人员看到。

表现层如图：
分布层服务层如图：

应用层如图：
领域层如图：

基础设施层如图：
事实上，我们在设计一个系统时，从架构师的角度应该要设计出上面的这些图来，这样你才能更好的驾驭你的项目，呵呵！

---

DDD~充血模型和失血模型

这几年，状态依旧不好，但在23点以后，状态还可以，所以，静下来，看点DDD，并把相关信息记载一下，今天是除夕，不过，我写文章时已经是大年初一了，呵呵，外面的炮声响亮，但我的内心很平静，也许是年龄大了，对于过年的感觉也已经淡化了吧，再或许是有些事情还放不在。

任务与目标

今年的任务挺多的，目标也确实有点大，压我的有点喘不过气来，对于年未，我们是放松的，因为一年的任何已经完成，目录也已经完成，所以是放松的；但当新的一年真的到来时，意味着你要去实现今年定的目标了，我们需要紧张起来了，需要向着那个目标去奋斗了，这种感觉是我喜欢的！

失血模型

失血模型简单来说，就是domain object只有属性的getter/setter方法的纯数据类，所有的业务逻辑完全由business object来完成，这种模型下的domain object被Martin Fowler称之为“贫血的domain object”

充血模型

将大部分单个的，自身的，逻辑都定义在domain object里，包括持久化逻辑，而BLL层只负责事务处理和逻辑组合，BLL层在这里不直接访问DATA层，它的调用图示一般为：

BLL（业务组合，事务封装）＝>domain object领域对象=>DAO(数据访问对象）

OK，对于领域驱动设计，我们对传统的POCO实体要进行必要的扩充，以符合DDD的原则。