DDD领域驱动设计

领域模型是软件项目的公共语言的核心，是领域专家和开发人员共同遵守的通用语言规则。

核心概念

领域模型与数据模型不同，领域模型表述的是领域中各个类及其之间的关系。

从领域驱动设计的角度看，数据库只不过是存储实体的一个外部机制，是属于技术层面的东西。

数据模型主要用于描述领域模型对象的持久化方式，先有领域模型才有数据模型。

领域模型需要通过某种映射而产生对应的数据模型，EF的CodeFirst是一个很好的体现。

领域模型对象分为实体、值对象、服务。

在领域驱动设计中，实体是模型中需要区分个体的对象。

通过对象属性值来识别的对象，将多个相关属性组合为一个概念整体。

相比实体而言，值对象仅仅是比实体少了一个标识。

实体拥有唯一标识，而值对象没有。

实体允许变化而值对象不允许。

判断实体相等的方法是判断实体的标识符是否相等

判断值对象相等的标准是值对象内部所有属性值相等

聚合标识一组领域对象（包括实体和值对象）用来表述一个完整的领域概念。

每个聚合都有一个跟实体，即聚合根。

领域驱动设计DDD将软件系统分为4层：

表现层 UI
MVC的Web项目，负责UI呈现。
应用层 Application
辅助性的一层，是整个项目的基础。主要包括仓储的实现（存放数据的地方）和通用支撑性的类库。
MCF服务，负责协调领域层的调用，向UI层提供所需接口。
领域层 Domain
DDD设计的核心，定义领域实体和领域逻辑。
DDD不但需要精确合理的表达出通用语言的每个细节，另外如何把对象合理的定义为聚合、实体、值对象也是重中之重。这不但关系着整个项目的复杂度，也是战术建模的体现，任何一行代码都是对业务的准确定义，应该是恰到好处。一个清晰简洁的战术建模才可以对应后续的快速变化。
基础结构层 Infrastructure
Infrastructure层的职责是对接收到的数据做一些非业务性验证，事务控制，最重要的是协调多个聚合之间的操作。
Infrastructure层应该清晰的表达出整个操作所做的事情，并与通用语言是一致的。
通用技术，如AOP、MEF注入、工具类、DTO模型层。

DDD项目的经典分层

领域驱动设架构计

image.png

DDD所使用的传统分层架构是松散的，也就是说，上层可以访问任意层级的下层，而不是仅限于当前层的下一层。

DDD中要提炼业务中的精华，合理的抽象为三个概念Entity、ValueObject、Aggregate，这种抽象是需随着领域里的概念变化而变化的。

实体 Entity
每个实体都是唯一的，相当长的一段时间内持续地变化。可对实体做多次修改，故一个实体对象可能和先前状态不大相同。但是，由于它们拥有相同的身份标识，它们依然是同一个实体。
值对象 ValueObject
值对象用于度量和描述事物，当你只关心某个对象的属性时，该对象便可作为一个值对象。实体与值对象的区别在于唯一的身份标识和可变性。
聚合 Aggregate
聚合类是实体的升级，是由一组与生俱来就密切相关实体和值组合而成的，这整个组合的最上层实体就是聚合。