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