业务模式
确定领域之后 ， 如何开始设计业务功能
核心域 - 领域模型建模
通用域- 开源方案
支撑域 - 事务脚本
过程模式 - 事务脚本
设计业务逻辑 ， 将其组合在业务逻辑层
业务就是如此这样的一条条的事务逻辑
好处是简单，问题也是过于简单。 属于是一个过程式的模块。
过程模式 - 表模块
基于数据库表的功能 ， 将功能全部放到了一起。 抽象程度只能到表，不能到行 。 所以现在很少使用了。
对象模式 - 活动记录
查询语义是静态的， 对于 Order 类 ，代表一行记录 ， 所以如果是静态的。
违反了单一功能原则 - SRP
对象模式 - 领域模型模式
关注真实世界里面期待的行为和数据 对象模型和现实世界匹配
常见实现业务方式 - 实战
贫血模型，作为调用者，需要知道的太多了
直接使用Dao完成全部的操作 ， 业务流程写到了存储过程中，是一个反模式
那么，符合DDD的设计 ， 修改订单的操作之前是交给Service操作，调用者不关心细节
调用者，只关心产品的ID 和需要修改的数量 就可以了
实体 - Entity
不要从数据驱动设计，即不关心数据库，不关心技术。 身份标识：业务上的唯一标志
- 属性
- 领域行为
身份标识
上述例子为什么不直接使用String：
因为有逻辑，需要封装一下生成String 的逻辑
在领域中的唯一标识称之为 领域实体标识 作用到数据库的时候，称之为委派标识
实体属性
说明主体的静态特征 分为基本属性和组合属性
组合属性的话，可能属性里面会有自己的业务逻辑。 - 也是一个值对象
值对象
值对象不应该是领域里面的东西，领域里面的东西是实体 值对象可以度量和描述领域里面的实体
在不同的界限上下文，一个事物可能是实体，也可能是值对象
聚合
类似上述这种的多对多的关系，真正的对象，其实每一个都有各种复杂的引用。 将已经封装好的对象，再次封装在一起，完成显示分组来表达整体的概念。
将一个复杂的对象图，逐渐拆分， 变为一个个独立的整体。 在这边就是在微观上划分标准。 （界限上下文是在宏观上划分标准）
聚合后，分为一个个小的个体，每一个小的事务一致性 ， 个体之间保证最终一致性。
例子： 在线考试的问题和答案可以放在一个聚合， 因为脱离问题，答案就无意义了。 知乎上的问题和答案不适合放到一个聚合
- 聚合根的实现应该和框架无关
- 聚合根之间的引用使用ID完成
- 聚合的所有变更都是由聚合根完成
- 一个事务设计更新多个聚合根，思考一下是不是划分出现了问题
- 尽量使用小聚合
微服务是和界限上下文相关， 一个界限上下文里面存在多个聚合
资源库 - Repository
Dao 只关心实体 ，但是 资源库获取的是一个聚合。
是一个很薄的一层，只负责基本的数据库访问的逻辑。
应用服务 - Application Service
应用服务是用来表达 use case 的 本身不具备业务逻辑 ， 只负责编排协调领域服务来实现实现用例。 应用服务可以存在分支 ， 但是分支里面的逻辑是比较少。
应用服务是一种 门面模式 - Facade
应用服务 = 只有调用顺序，没有业务逻辑的事务脚本
DTO 转换
DTO - 数据传输对象 ， 是交给前端的对象 ， 将后台的实体和前台展示对象分离。 类似前台展示的Bean。
也存在一些框架完成 Entity 和 DTO 的转换。
领域服务 - Domain Service
对于跨实体的业务逻辑，放在任何一个实体都是不太合适的。 所以我们继续抽出一层，即领域服务层。
- 领域服务是和业务逻辑相关
- 应用服务是和用例相关
Domain Service 也可以完成调用第三方的服务 - 属于业务逻辑的一部分
领域事件
