前言: 实体具有业务属性、业务逻辑和业务行为,是是实实在在的业务对象。在事件风暴中,我们可以根据命令、操作与事件将业务上紧密结合在一起的多个实体与值对象进行聚合形成聚合根。
实体是什么
虽然数据库的设计占据了主导地位(这个是没错的),但开发者也不应该只关注数据,而且要关注模型。数据+行为= 模型,实体就是含有领域概念的模型。它是一个唯一的东西,在相当长的时间里数据状态在持续地变化,并且一定有唯一键,这区别于值对象。注意的是如果非要用表结构里的一条含有主键的数据去理解实体也是可以的,但不少情况下可能是有多个表或者k/v数据来组成的一个实体。
实体、值对象与数据模型示例
实体是可变的,是变性,每个用户实体都有自己的唯一性,我们用id来进行区分。值对象是不变的,是共性,实体都有相同的值对象,例如国家等信息。我们以此区分好实体与值对象。
为什么使用实体
如果开发者设计系统时,并没有建模而是直接开始设计表结构和它的CRUD
,其实这也算是建模的一种,但这种方式仅仅能应对简单的模型。这样的操作当更复杂的业务和更复杂的模型出现后是驾驭不了的。假设我们做10平米的卧室设计,那么简单的量一下桌椅床就ok
。但如果我们设计一个200平米的化学实验室的时候,这个简单的摆放可能搞不好会导致爆炸吧~
唯一标识
在实体的设计早期,我们将关注点都放在了实体的身份唯一性、属性、行为上。同时还应该关注对实体的查询和创建,我们首先要考虑实体的本质特征,特别是实体的唯一标识符,它是一个关系节点。比如用户这个实体username
是不是唯一标识,如果不是唯一,是不是可以通过username
去查找。
实践
https://github.com/8treenet/freedom/tree/master/example/fshop/domain/entity
- 所有的
entity
都必须继承freedom.Entity
接口, 这里为实体注入了领域事件和运行时的Worker
对象。 - 所有的
entity
都必须重写Identity() string
方法。 - 实体可以选择的继承
PO
或者DTO
,