ddd

DDD理解：
基本概念：
DDD战略思想：领域、子领域、限界上下文、通用语言、下文映射图、架构风格
DDD战术实现：聚合、实体、值对象、聚合根、领域服务、应用服务、仓储、事件模型、CQRS、时间溯源

订单的边界在哪里？
订单的聚合根

适配器包装对外部系统的依赖，系统内部依赖适配器，由适配器调用外部接口
子域、子子域、领域树

子域 = 核心域（桃树、桃花）、支撑域（强业务相关，但又非核心）、通用域（稳定与高兼容性）
上下文决定子域划分的差异

上下文映射图： 电商领域的两个子领域（订单领域和物流领域） 都存在商品这个属性，商品信息会随着业务从订单上下文流转到物流上下文

两个上下文之间不直接进行交互而是通过定义防腐层接口进行交互
领域/子域的呈现方式 -- 聚合
实体 与 值对象 用来描述聚合内部的属性
实体 = 唯一标识 + 生命周期 (实体属性可变)

值对象 ：生成之后具有不可变性，属性值一致就认为是同一个物体（例如：订单地址）
如果需要对值对象进行修改，那就整体替换
值对象 = 不变性 + 通过属性判断相等（没有唯一标识）

聚合是领域的抽象体现，包含了当前领域的一切事物
聚合根是领域的具体体现，是一种特殊的实体，其内部定义了当前领域需要的业务属性（实体+值对象）
例如：订单领域的具体体现就是订单聚合根（订单明细实体、地址值）
聚合根 = 领域强关联的实体、值对象 + 核心业务逻辑

实体、值对象, 聚合根的关系：
1.包含关系（聚合根包含了实体和值对象）
2.生命周期由聚合根维护。值对象不存在生命周期，只能被整体替换
3.标识关系： 聚合根本身也是实体，ID就是他的唯一标识。值对象在聚合和内部的唯一性通过 属性相等 判断实现

应用服务层 与 领域服务层
应用服务层: 功能用例层，例如 新建用户， 这个功能可以放在应用服务层， 但新建用户的逻辑业务处理应该放到 用户聚合根内部，应用服务层只负责调用定义在聚合根内部的方法。应用服务层类似于MVC的Service，应用服务层只做逻辑编排，例如参数校验、外部服务调用、聚合根方法调用、持久化聚合根等 于 业务流程走向相关 但与逻辑无关的代码。 外部服务通过访问应用服务提供的接口执行功能用例

仓储:为了桥接数据模型和领域模型，（持久化聚合与检索聚合），让应用服务专注逻辑编排，聚合根专注逻辑处理，不用关心吃句话发哪个会与存储介质

事件模型
用户下完订单还需要给用户增长积分和赠送优惠券，在应用服务内实现，我已经完成订单了却还需要带哦用用户积分和优惠券的外部接口。这不合理，所以提出了事件模型。下单完成之后发布一个领域事件，让需要感知这个事件的服务自行监听并处理

问题1：界定出一个系统中有多少个聚合，即划分多少个业务模型
问题2：界定出每个聚合之间的限界上下文，即划分清楚领域的业务边界