DDD基本概念
DDD是复杂系统设计方法论，核心设计思想：将对软件的分析与设计还原到真实世界中。
系统增删改的业务适用于领域驱动设计，数据分析场景不适合。例：订单与订单明细场景，统计所有订单明细的商品，不可能去查询出订单，再查出订单明细，再统计商品数据分析。
实体
通过一个唯一标识来区分真实世界中每一个个体的领域对象。
例：身份证号来区分人。
值对象
真实世界中一成不变、本质性的事物。
例：人民币是一种币种，北京是一个城市。
某一事物是值对象或实体对象在不同场景下不一样。
例：菜单与饭店，如果每个饭店的菜单都是同一个对象，那么就是值对象；否则就是实体。
聚合
整体和部分的关系，整体和部分生命周期一致。
例：订单与订单明细
聚合根
外部访问的唯一入口，不能越过整体访问部分。
例：订单与订单明细中的订单。
工厂
通过聚合根唯一标识，调用DAO去数据库中查询各个实体对象，装配成聚合对象。
例：通过订单ID分别查询订单对象、订单明细对象、下单用户信息对象，然后将订单明细、用户信息塞入订单中，装配成完整的订单领域对象。
仓库
调用工厂获取装配好的领域对象，也拥有缓存领域对象的能力。
例：通过订单ID查询订单领域对象时，先去缓存中查找，如果找到了，返回；没有找到，调用工厂获取。
充血模型
存在聚合的概念，service->repository->factory。
贫血模型
胶水式代码，可以越过聚合根访问聚合中的对象，service->dao。
限界上下文
问题域：真实世界的业务与问题。
问题子域：对复杂问题域进行细分，分而治之，每个子域都是独立的业务场景。
业务领域知识：业务规则与知识。
以子域为中心进行领域建模绘制出一张一张的领域模型设计就是限界上下文。满足单一职责原则，每个限界上下文实现的都是软件变化同一个原因的业务。
限界上下文内部应该高内聚，限界上下文之间低耦合。
指导解决划分微服务。
例：用户下单场景中，用户信息不该在用户下单的限界上下文中实现，应由用户信息管理限界上下文提供，用户下单上下文调用用户信息管理上下文接口。
统一语言
开发与业务沟通时，统一业务领域知识，规范专业名词，形成统一语言。
例：面向中医客户时，症状-》表象，疾病-》证候。
领域事件
已经发生并且需要保存的重要事实，涉及数据状态的更改。
例：用户选餐不属于领域事件，只涉及数据的查询。
实践原则
- 需求分析、领域建模，建立多个问题子域。
- 将问题子域落实到限界上下文，之间的关联形成上下文地图。
- 各子域落实到微服务中贫血模型或充血模型的设计，从而在微服务之间依据上下文地图形成接口。
