软件生产与模型（二）：模型描述(实体、值对象、服务)

在软件生产与模型：分离领域中，通过分层隔离出了领域层，这样我们就可以集中关注点。那么在具体的模型中，怎么表示模型呢？

模型描述

用来表示模型的元素的3种元素分别为：实体(entity)、值对象(Value Object)、服务(Service)。

 

实体（又称引用对象）

以标示作为其基本定义的对象称为实体。有时，一个对象与另外一个对象，有着不同的属性，但它却是同一个对象，有时，一个对象与其他对象有着相同的属性，但必须能够和哪些对象区分开来。对于实体而言，我们关注的重点不是它的属性或者行为，而应该把繁枝茂叶从定义中除去，只剩下哪些固有特征。

比如，对于一个人来说，它都有一个身份证，那么不管他在长大、衰老的过程中发生了多少变化，他仍然是那个人，这段时间他可能市区某些关联(父母的死去)，也获得某些关联(子女的诞生)，他可能获得某项本来不会的技能，或者因为某些原因失去本来会的技能，总之他会经历很多变化，但是他还是他。它体现了表示在时间上的延续性，经常要经历很多中不同的形态。

如果一个对象通过标识而不是属性来确定，那么就在模型中把标识作为这个对象定义的基本要素。确保生成标识的操作能够为每个对象产生一个唯一的结果，这可以通过在标识中附加一个具有唯一性保证的符号来实现。不管使用什么方法，标识必须满足其在模型中所具有的唯一性。模型必须对"怎样才是同一个事物的具体含义做出定义"。

 

值对象

如果一个对象代表了领域中的某种描述性特征，并且没有概念性的标识，就成为值对象。值对象可以是其他对象的集合，甚至可以引用实体。例如，一条从旧金山到洛杉矶之间的行车路线，可能它是一个路线（Route）对象。这个Route对象可能是一个值，不过它设计的3个对象是实体(两个城市和一条高速公路)。

 

实体与值对象

一个对象所代表的事物是一个具有连续性和标识的概念（可以跟踪事物精力的不同状态，甚至可以让该事物跨越不同的实现），还只是一个用来描述事物的某种状态的属性。这就是实体与值对象最基本的区别。

在我的眼中，实体与值对象，在一定程度上，也是取决与关注者的角度。比如，对于一个航运中的货物，在计算机中，这批货物有一个唯一的标识，那么不管在路上发生了什么，在计算机中它仍然是那批货物。然而，对于收货的人来说，他要的是具体的货物，如果在航运的途中，丢失了一些物品，那么在他眼中，这已经不是那批物品，不会因为有一个相同的标识而认为这就是那匹货物。他会要求重发或者补偿。

一个网友所说：

判断一个对象是实体还是值对象，还要根据它在具体的业务领域中的实际意义来决定，比如：体育馆里的座位，当业务领域这样规定，一张门票对应一个特定的座位，即每个座位都应该严格区分谁是谁，观众在选择座位时根据门票对应的座位号来选择这个唯一的座位，此时座位对象应该为实体。

但当业务领域改变规则，决定只要有门票，就可以进去随便坐，此时不需要明确哪个座位是哪个座位，只要有座位就可以坐下，每个座位都是同一个座位对象的副本（在某些场合可以通过共享一个对象来提高性能），无须区分谁是谁，此时座位对象应该为值对象。

服务

领域中的一些概念不能作为模型中的对象来处理。将领域需要的功能强行加到实体和值对象中，不仅破坏模型中对象的定义，而且还会认为的添加没有意义的对象。

服务作为一种接口提供操作，它独立于模型，没有像实体和值对象那样封装状态。服务在技术框架中是一种通用模式，但是它也可以应用于领域层。

服务也分很多层上的服务，比如，一个封装电子邮件发送的接口属于基础结构层上的服务。对于应用层和领域曾的服务区分起来有难度，一个基本的原则就是：它是否具有业务意义，如果有则是领域层的服务，否侧为应用层服务。

比如，将资金从一个账户转到另一个账户的功能，便是一个领域服务，因为它包含明显的业务规则，将转账操作赋予对象非常难于操作，因为操作包含了两个账户和一些全局规则；又比如银行有一种应用可以将我们的交易转化并输出成电子表格文件提供下载，这就是一个应用服务，它没有任何业务规则。

 

服务的粒度

服务的零度分的太细，会导致消息在分布式系统中低效率的传递，而且也会导致信息从领域层转到应用层。中等粒度，无状态的服务在大型系统中很容易被重用。

<!--EndFragment-->