领域建模
领域模型
- 构建领域模型
- 从业务描述提取对象及关系（继承、关联、包含等），类似类图
- 写下来的领域模型，可以澄清不同参与者的内心假设，发现潜在的概念冲突和不一致的地方
- 用共同的价值来推动
- 业务规则 -> 业务场景 -> 业务目标
- 需求评审期间记录概念
- 用领域模型来指导实现
- 领域模型图类似类图，可以直接转换为类
- 实体对象 - 值对象 - 领域事件 - 领域服务
- 聚合 - 是业务逻辑的边界，根是业务逻辑唯一对外暴露的接口，比如要访问采购项，必须访问采购请求
- 子域 - 比如文档内可以发表评论，评论内部又可以划分为可评论资源、评论 、评论者，子域用于分解问题
实体
实标对象（Moment-Interval）：随着时间的改变，该对象会发生变化，比如采购计划。它的变化往往代表着关键业务的转移，比如被审批、被提交、入库等等。比起他对象更值得关注。在DDD模型中被称为实体对象。
实体——和业务紧密相关
- 有状态
- 基于标识唯一识别一个对象
- 实体状态（属性）的变化不会影响到对象的识别（可以对比采购单和采购项来理解，一个采购单不会因为状态改变了就不再是那个采购单了，但是采购单中的一个采购项如果变化了，它没必要还是原来的采购项，可以是多个）
值对象
值对象本身是无状态的，不可变，没有唯一标识，从这个层面上来讲，值对象可以理解为实际的Entity对象的一个属性的结合，该值对象附属在一个实际的实体对象上面。值对象本省不存在一个独立的生命周期，也一般不会产生独立的行为。
领域服务
订单生成策略、供应商选择策略。建一个单独的对象，而不要挂在一个毫无关系的对象上。
领域事件
采购计划被创建，这种代表一种业务事实发生的东西统称为领域事件。也需要显式的建模在领域模型中。
聚合
聚合是业务逻辑的边界。突破逻辑边界对内部对象进行操作，会破坏业务逻辑的完整性。
解决方案：所有对聚合的更新都应该通过聚合根来进行。
- 外部对象不允许直接访问聚合的内部实体
- 在聚合边界内，对象之间可以相互引用。但是根是聚合中唯一允许被外部引用的元素
联想老师提到的采购计划和采购项来理解，区分领域层和业务层。