IDDD 摘要

第一章 DDD入门

领域专家并不是一个职位，他可以是精通业务的任何人。他们可能了解更多的关于业务领域的背景知识，他们可能是软件产品的设计者，甚至可能是销售员。

领域模型是关于某个特定业务领域的软件模型。通常，领域模型通过对象模型来实现，这些对象同时包含了数据和行为，并且表达了准确的业务含义。

贫血领域对象描述了一个缺少内在行为的领域对象。特征如下：

• 领域对象中主要是些公有的getter和setter方法，几乎没有业务逻辑。
• 软件组件经常使用的领域对象包含了系统的主要的业务逻辑，并且多数情况下你需要调用那些getter和setter。比如controller层set各种属性。

通用语言是团队共享的语言。领域专家和开发者使用相同的通用语言进行交流。

第二章 领域，子域和限界上下文

从广义上讲，领域即是一个组织所做的事情以及其中所包含的一切。

领域被分成若干子域

核心域是业务成功的主要促成因素。

支撑子域对应着业务的某些重要方面，但却不是核心。

通用子域被用于整个业务系统。

限界上下文是一个显式边界，领域模型边存在于边界之内。在边界内，通用语言中的所有术语和词组都有特定的含义，而模型需要准确的反映通用语言。

比如账户：

在银行上下文，账户表示一个客户在银行的存款状态，并记录每次交易信息。eg.支票账户和储蓄账户。

在文学上下文，账户表示用文字记录的在一段时间内发生的一系列事情。eg.亚马逊卖出某个书

第三章 上下文映射图

上下文映射图可以用来两种方式来表示。比较容易的一种是画一个简单的框图来表示多个限界上下文的映射关系。

第四章 架构

DDD的一大好处便是它并不需要使用特定的架构。由于核心域位于限界上下文中，我们可以在整个系统中使用多种风格的架构。

• 分层架构

依赖倒置原则通过改变不同层之间的以来关系来改进分层架构，定义：高层模块不应该依赖于底层模块，两者都应该依赖于抽象。抽象不应该依赖于细节，细节应该依赖于抽象。

• 六边形架构（端口和适配器）

在这种架构中，不同的客户通过“平等”的方式与系统交互。需要新的客户吗？只需要添加一个新的适配器蒋客户输入转化成能被系统API所理解的参数。同时系统输出，比如图形界面，持久化和消息等都是可以通过不同的方式实现，并且是可以互换的。

• 面向服务架构（SOA）

1. 服务器契约        通过契约文档，服务阐述自身的目的与功能
2. 松耦合                服务将以来关系最小化
3. 服务抽象            服务只发布契约，而向客户隐藏内部逻辑
4. 服务重用性         一种服务可以被其他服务所重用
5. 服务自治性        服务自行控制环境与资源以保持独立性
6. 服务无状态行     翻译网页负责消费放的状态管理
7. 服务可发现性      
8. 服务组合型        一种服务可以由其他的服务组合而成

• REST（REpresentation State Transfer)

REST作为一种架构风格。架构风格之于架构就像是设计模式之于设计一样。它将不同架构实现所共有的东西抽象出来，使得我们在谈及到架构时不至于陷入技术细节中。

1. 资源是关键的概念，作为一个系统设计者，你决定哪些有意义的“东西”可以暴露给外界，并且给这些“东西”一个唯一的身份标识。
2. 它是无状态通信。我们不能依靠请求本身来创建一个隐式上下文环境（对话）。PS这里指http协议是无状态的，在内容头里放上seesionId是我们自行添加的。
3. 它可以调用的方法集合是固定的。每个对象（或者说是资源，东西）都支持相同的接口。在RESTful中，对象方法便可以表示为可以操作资源的HTTP动词，其中最重要的是GET PUT POST和DELETE。对应CRUD操作，但不准确。我们所创建的资源并不表示仁和持久化实体，而是封装了某种行为。

为什么使用REST？

• 松耦合，添加新资源链接到老资源是非常简单的
• 分成多个模块，易于理解，测试等。
• 和HTTP本身的动作设计很匹配。

HATEOAS：hypermedia as the engine of application state，简单来讲，就是单个资源并不独立存在，不同资源是相互链接在一起的。

• 命令与查询职责分离 ----  CQRS（Command Query Responsibility Segregation）

定义：一个方法要么执行某种动作的指令，要么是返回数据的查询。

这意味着：

如果一个方法修改了对象的状态，该方法便是一个命令。比如方法声明成void。

一个方法返回了数据，该方法就是一个查询。

第五章 实体

唯一的身份标识和可变性特征将实体对象和值对象区分开来。

值对象可以用于存放实体的唯一标识，因为值对象是不变的。

在面向对象编程中，通常由接口来定义实现类的角色。在正确设计的情况下，一个类对于每一个它所实现的接口来说，都存在一种角色。如果一个类没有显示的角色，即该类没有实现任何显示接口，那么它扮演的就是本类的角色。

第六章 值对象

• 它度量或者描述了领域中的一件东西。
• 它可以作为不变量
• 它将不同的相关的属性组合成一个概念整体
• 当度量和描述改变时，可以用另一个值对象予以替换。
• 它可以和其他值对象进行相等性比较。
• 它不会对协作对象造成副作用。（无副作用行为：因为只会替换，不能修改，所以值对象不会变）

jpa怎么存值 @lob 能存list？

第七章 领域服务

领域中的服务表示一个无状态的操作，它用于实现特定于某个零年于的任务。当某个操作不适合放在聚合和值对象上时（这里没有提到实体），最好的方式便是使用领域服务了。有时我们倾向于使用聚合根上的静态方法来实现这些操作，但在DDD中，不能这样做。

大约就是service层。

第八章 领域事件

定义：领域专家所关心的发生在领域中的一些事件。将领域中所发生的活动建模成一系列的离散事件。每个事件都用领域对象来表示。

其实就是消息啦。书中示例：存储可以用数据库，传输可以用消息中间件，发送事件用切面。

第九章 模块

模块和领域概念保持协调一致	一个或一组内聚的聚合对应一个模块
根据通用语言来命名模块
不要机械式的根据通用的组件类型和模式来创建模块	不要所有都按service，factory，domain，vo等来创建包。先分领域模型
设计松耦合的模块
当同层模块间出现耦合时，我们应该杜绝循环依赖。	尽量消除同层模块之间的双向依赖
在父模块和子模块之间放松原则	尽量避免父子之间的循环依赖。比如父模块的对象创建一个子模块的对象，而子模块对象又需要维护对父模块对象的引用。
不要将模块设计成一个静态的概念，而是与模型中的对象一道进行建模	如果模型概念改变了，应该重构。

com.公司名.项目名.domain.model.子模块.子子模块 下面放模型的类，接口和抽象类。比如：ConcurrencySafeEntity,DomainEvent,DomainEventPulisher,DomainEventSubscriber,DomainRegistry,Entity,IdentifiedDomainObject,IdentifiedValueObject.

com.公司名.模块名.domain.service.子模块.子子模块 下面放领域服务。

第十章 聚合

将实体和值对象在一致性边界之内组合聚合。

原则

• 在一致性边界之内建模真正的不变条件（比如事务一致性）
• 设计小聚合
• 通过唯一标识引用其他聚合 （jpa的引用对象可以保证吗？不能，但只保存id能怎么弄？）
• 在边界之外使用最终一致性

迪米特法则：又叫最小知识原则。考虑一个客户端对象需要调用系统中其他对象的行为方法的场景，此时我们可以将后者称为服务对象。在客户端使用服务端对象时，它应该尽量少地之道服务对象的内部结构。

告诉而非询问原则：客户端不应该首先询问服务对象，然后根据询问结果调用服务对象中的方法，而是应该通过调用服务对象的公共接口方式来“告诉”服务对象索要执行的操作。（服务对象应该提供接口让客户端直接完成操作，而不是客户端拿到服务对象自己进行操作）

前者限制性更强，它只允许客户端通过聚合根进行访问。后者允许客户端访问聚合根的内部，但是它也要求对聚合状态的修改应该属于聚合本身，而不是客户端。

hibernate hook，对象声明周期？？？

第十一章 工厂

这张关注的是在领域模型中使用工厂，所以不一定是factory类或者方法。

不一定是单独写个Factory工厂类，可能只是领域服务或者领域对象的某个方法。客户端调用服务端所传的参数会少些，服务端可以隐藏某些逻辑。

第十二章 资源库

只有聚合才拥有资源库。

• 面向集合资源库:一个资源库应该模拟一个set集合。无论采用什么类型的持久化机制，我们都不应该允许多次添加同一个聚合实例。另外，当从资源库中获取到一个对象并对其进行修改时，我们并不需要重新保存该对象到资源库中。JPA？？
• 面向持久化资源库：在向数据存储中添加新建对象或修改既有对象时，我们都必须显示地调用put（）方法，该方法将以新的值来替换先前关联在某个键上的原值。更像map？

第十三章 集成限界上下文

通过发布事件来进行逻辑解耦.

跟踪器记录了重试时间和重试次数，绑定了领域对象，也可以一起持久化到数据库。每个流程都可以调用跟踪器来判断是否超时而作相应的操作。还可以写一个定时器，定时检查跟踪器的状态，触发超时事件。