DDD领域模型

注：这是很抽象的概念，尽量举例，让概念更好理解。

定义：聚合是用来定义领域所有权和边界的。

定义：
一个由它的标识定义的对象叫做实体；
具有唯一标识性和可变性；
它是具有业务逻辑；
对应现实世界一个具体的业务对象。

简而言之，就是把多个相关的值与对象整体堪称一个域，简化整体的关系。

领域即问题域，通常是根据一个组织所处的行业进行识别，
它基于业务的愿景，定义了系统要解决的现实问题的目标和范围。
领域越大，业务的范围也越大，大的领域可以拆分成小的问题域，称之为子域。
根据子域重要性和功能属性划，可以将其分为三类：核心域、支撑域和通用域

简单来说，对于产品可以把领域理解为这个产品所解决的问题。

例如抖音，为了就是输出内容，商户打广告等等平台，且想留存用户在抖音内消费等等功能的产品
- 核心
  1. 需要优质的内容输出机制，吸引用户创作
  2. 需要吸引用户留存，提高用户体验
  3. 让商家看到抖音的用户潜力，吸引商家入驻在这投放广告，让用户创作更好的优质内容。
例如微信，让腾讯内的产品切入到生活的方方面面
- 核心
  - 优质的社交用户体系体验，留存了很多用户（微信好友，通信功能）
- 支撑域
  - 微信的用户生态-腾讯其他产品的支撑域名
  - 朋友圈，微信支付，微信好友
- 通用域
  - 公众号，订阅号消息，短信等等
例如懂车帝，可能上面的体系太大不太清楚其中的关系；懂车帝主要解决选车的问题
- 核心
  - 车型信息（类型，价格，性能参数）
- 支撑（使用户在这里作出抉择，用户留存）
  - 车辆对比（里程，价格，品牌，容量等等）
  - 用户测评
  - 新品发布
  - 各地补贴消息
  - 车友圈
- 通用
  - 支持服务…
  - 脏词子域
  - 日志子域
  - 监控子域
  - ip子域

将整个环节的主要部分划分开来。

电商场景下的购买：

一致性事务边界
- 边界不清会导致，整体的事务重，会影响并发或者扩容资源浪费等等问题
- 边界划分很大的时候，状态很难捕捉。（想一想，购物车，下单，支付，物流等等都在边界内，是很难确认流程重存在的问题）
- 保持域内的事务一致性，能更好管理整体流程的完整
- 领域事件，通过捕捉某个领域的事件或者异常，通过消息队列给到别的领域去消费