此文想聊一聊软件系统设计中可能会被日常认知所干扰的判断。
业务场景上下文：
新电影开拍，导演需要选择主角。
如果这个时候我们要构建一个给导演用的选角App，我们用DDD的方法论来考虑问题，可能会觉得，演员是个实体。不，其实演员应该是个值对象。
--什么？此处演员是个值对象？主角是个人， 是个实例，为什么DDD中就不是个Entity了？
为什么我们会觉得演员应该是实体，是因为现实生活的认知是，他们的名字就直接映射到了演员这个人，是谁，特点是什么，颜值等信息一瞬间被激活在意识里。我们会直接联系到真实演员的“实例”。
OK。DDD的选角App建模问题应该这样来讲故事会比较好理解吧。
电影开拍前要选角。外籍导演不认识演员也没听说过演员的名字，根据电影题材就只能靠演员身材条件来确定主角。演员经纪人负责与剧组联系并提供一张演员照片参与选角。不幸的是，硬朗帅气身材好的演员的照片被经纪人搞错了，发过来另一位谐星的照片。这种情况下，如果我们再说DDD分析建模，演员在选角App中是实体还是值对象？
此时演员是个值对象而不是实体。因为这个场景中，外籍导演，照片，甚至经纪人，都在刻意构建导演与演员之间不连接的边界。有了这些边界的隔离，我们才能看清，此时导演只能依据一些照片提供的身高， 身材，颜值等值类型去做判断，那当然演员这个对象在导演眼里就只有几个值类型而已。而进一步说，能够胜任主角的演员特质，其实都是值类型，都是实例演员某一时刻（照片中或者你脑海中）的各个值类型属性集合。
惊不惊喜，选角系统的演员真的是值类型。
发散一下，照片应该是个实体，照片有标识。所谓演员的外在属性，其实是照片的属性。颜值与外型都是照片的值对象。然后呢，如果选角上下文暂时结束，照片这个实体应该成为下一个上下文-试镜的关键输入，因为可能需要靠照片找到对应的经纪人以及对应的演员实体。
书里的依据：
- [P49]一个对象是用来表示某种具有连续性和标识的事物？还是用于描述某种状态的属性呢？这是Entity与Value Object之间的根本区别。明确地选择这两种模式中的一个来定义对象，有利于减少歧义，并帮助我们做出特定的选择，这样才能得到健壮的设计。
- [P59]当一个对象由其标识而不是属性区分时，那么在模型中应该主要通过标识来确定该对象的定义。
- 要格外注意那些需要通过属性来匹配对象的需求。
- 每个对象分配ID系统就必须处理所有这些ID的跟踪问题。（所以处理不正当的Entity是一件增加复杂度的事情。）
- 软件设计要时刻与复杂性做斗争。我们必须区别对待问题。仅在真正需要的地方进行特殊处理。（识别为Entity）
