01 | 领域驱动设计：微服务设计为什么要选择DDD？
02 | 领域、子域、核心域、通用域和支撑域：傻傻分不清？
03 | 限界上下文：定义领域边界的利器
04 | 实体和值对象：从领域模型的基础单元看系统设计
实体对象拥有唯一标识符
值对象没有标识符
也就说，值对象描述了领域中的一件东西，这个东西是不可变的，它将不同的相关属性组合成了一个概念整体。当度量和描述改变时，可以用另外一个值对象予以替换。它可以和其它值对象进行相等性比较，且不会对协作对象造成副作用。这部分在后面讲“值对象的运行形态”时还会有例子。
值对象只是若干个属性的集合，不包含业务逻辑；值对象属性也是实体属性的一部分
从这个例子中，我们可以看出，同样的对象在不同的场景下，可能会设计出不同的结果。有些场景中，地址会被某一实体引用，它只承担描述实体的作用，并且它的值只能整体替换，这时候你就可以将地址设计为值对象，比如收货地址。而在某些业务场景中，地址会被经常修改，地址是作为一个独立对象存在的，这时候它应该设计为实体，比如行政区划中的地址信息维护。
05 | 聚合和聚合根：怎样设计聚合？
在事件风暴中，我们会根据一些业务操作和行为找出实体（Entity）或值对象（ValueObject），进而将业务关联紧密的实体和值对象进行组合，构成聚合，再根据业务语义将多个聚合划定到同一个限界上下文（Bounded Context）中，并在限界上下文内完成领域建模。
第 5 步：多个聚合根据业务语义和上下文一起划分到同一个限界上下文内。
