领域驱动设计学习笔记

1 概念

1.1 一个通用领域驱动设计的架构性解决方案包含4 个概念层:

表示层	负责向用户展示信息，及解释用户的命令
应用层	很薄的一层，用来协调应用的活动，他不含业务逻辑，他不保留业务对象的状态，但保留应用任务的进度状态。
领域层	本层包含关于领域的信息，这是业务软件的核心所在，在这里保留业务对象的状态，对业务对象和他们状态的持久化被委托给了基础设施层。
基础设置	本层作为其他层的支持库存在，他提供了层间的通信，实现对业务对象的持久化，包含对界面层的支持库等作用

1.2 4层模型间的关系

1.3 设计模型图

2 领域驱动模型的一些要素

2.1 实体(Entity) & 值对象(Value Object)

实体与面向对象中的概念类似，在这里再次提出是因为它是领域模型的基本元素。在领域模型中，实体应该具有唯一的标识符，从设计的一开始就应该考虑实体，决定是否建立一个实体也是十分重要的。

值对象和我们说的编程中数值类型的变量是不同的，它仅仅是没有唯一标识符的实体，比如有两个收获地址的信息完全一样，那它就是值对象，并不是实体。值对象在领域模型中是可以被共享的，他们应该是“不可变的”（只读的），当有其他地方需要用到值对象时，可以将它的副本作为参数传递。

2.2.服务(Services)

当我们在分析某一领域时，一直在尝试如何将信息转化为领域模型，但并非所有的点我们都能用Model来涵盖。对象应当有属性，状态和行为，但有时领域中有一些行为是无法映射到具体的对象中的，我们也不能强行将其放入在某一个模型对象中，而将其单独作为一个方法又没有地方，此时就需要服务.

服务是无状态的，对象是有状态的。所谓状态，就是对象的基本属性：高矮胖瘦，年轻漂亮。服务本身也是对象，但它却没有属性（只有行为），因此说是无状态的。

服务存在的目的就是为领域提供简单的方法。为了提供大量便捷的方法，自然要关联许多领域模型，所以说，行为(Action)天生就应该存在于服务中。

服务具有以下特点：

• a)服务中体现的行为一定是不属于任何实体和值对象的，但它属于领域模型的范围内
• b)服务的行为一定涉及其他多个对象
• c)服务的操作是无状态的

2.3.模块(Moudles)

对于一个复杂的应用来说，领域模型将会变的越来越大，以至于很难去描述和理解，更别提模型之间的关系了。模块的出现，就是为了组织统一的模型概念来达到减少复杂性的目的。而另一个原因则是模块可以提高代码质量和可维护性，比如我们常说的高内聚，低耦合就是要提倡将相关的类内聚在一起实现模块化。

模块应当有对外的统一接口供其他模块调用，比如有三个对象在模块a中，那么模块b不应该直接操作这三个对象，而是操作暴露的接口。模块的命名也很有讲究，最好能够深层次反映领域模型。

3.聚合(Aggregates)

聚合表示一组领域对象(包括实体和值对象)，用来表述一个完整的领域概念。而每个聚合都有一个根实体，这个根实体又叫做聚合根。举个简单的例子，一个电脑包含硬盘、CPU、内存条等，这一个组合就是一个聚合，而电脑就是这个组合的聚合根。在聚合中，根是唯一允许外部对象保持对它的引用的元素，而边界内部的对象之间则可以互相引用。除根以外的其他Entity都有本地表示，但这些标识只有在聚合内部才需要加以区别，因为外部对象除了根Entity之外看不到其他对象。

2.4.工厂(Factory)

一个对象的创建可能是它自身的主要操作，但是复杂的组装操作不应该成为被创建对象的职责。组合这样的职责会产生笨拙的设计， 也很难让人理解。因此，有必要引入一个新的概念，这个概念可以帮助封装复杂的对象创建过程，它就是工厂(Factory)。工厂用来封装对象创建所必需的知识，它们对创建聚合特别有用。当聚合的根建立时，所有聚合包含的对象将随之建立。

2.5.资源库(Repositories)

资源库的是封装所有获取对象引用所需的逻辑。领域对象不需处理基础设施，以得到领域中对其他对象的所需的引用。只需从资源库中获取它们，于是模型重获它应有的清晰和焦点。

资源库会保存对某些对象的引用。当一个对象被创建出来时，它可以被保存到资源库中，然后以后使用时可从资源库中检索到。如果客户程序从资源库中请求一个对象，而资源库中并没有它，就会从存储介质中获取它。换种说法是，资源库作为一个全局的可访问对象的存储点而存在。

Repository的接口应当采用领域通用语言。作为客户端，不应当知道数据库实现的细节。

Repository和DAO的作用类似，二者的主要区别：

DAO是比Repository更低的一层，包含了如何从数据库中提取数据的代码。

Repository以“领域”为中心，所描述的是“领域语言”。Repository把ORM框架与领域模型隔离，对外隐藏封装了数据访问机制。

2.6.规约(Factory)

规约是一种布尔断言。

规约是业务规则的 部分 理论上规约类中的方法只有个：isSatisfiedBy(Object obj)。

规约用来测试对象是否满足某种条件，用来进行对象查询，也可以作为某个对象的创建条件。

单一规约规则。多个规约通过组合表现复杂的规约。

2.7.限界上下文(Bounded Context)

明确的定义模型所应用的上下文。根据团队的组织、软件系统的功能和物理表现(代码数据库)来设置模型的边界。在这些边界中严格保持模型的一致性，而不要受到边界之外问题的混淆。每个团队负责自己的模型，并为其他模型提供服务。

2.8.上下文映射(Context Map)

一个企业应用有多个模型，每个模型有自己的界定的上下文。建议用上下文作为团队组织的基础。在同一个团队里的人们能更容易地 沟通，也能很好地将模型集成和实现。但是每个团队都工作于自己 的模型，所以最好让每个人都能了解所有的模型。上下文映射(Context Map)是指抽象出不同界定上下文和它们之间关系的文 档，它可以是像下面所说的一个试图(Diagram)，也可以是其他任 何写就的文档。详细的层次各有不同。它的重要之处是让每个在项 目中工作的人都能够得到并理解它。