从简单到复杂依次为:

3.1.1 用户提供唯一标识

这时用户将输入一些可识别的数值或符号,或从已有标识中选其一,然后创建实体对象。这是一种非常简单方案,但也可能变得复杂。
由于需用户自己生成高质量的标识。所以标识可能唯一,却有可能是不正确的。

缺陷

多数情况下标识不可变,用户无法修改标识。但有时赋予用户修改标识值的权限有好处。

例如,若将Forum和Discussion的名字作为唯一标识,那么发生拼写错误时怎么办,或用户之后想采用新名字怎么办?

  • Forum名字拼写错误,Discussion名字长度小于所要求的
    在这里插入图片描述

要改变这些标识值需要多大代价?虽然用户提供的身份标识看似一种节约成本的做法,但也有可能不是。此时我们还可以依赖用户来提供唯一的、正确、稳定的对象标识吗?

为避免上述问题,需重新设计。开发需采用无故障的方法来保证用户输入的确是唯一的身份标识。虽然基于工作流的标识审批过程,对于高吞吐量的领域并无多大帮助,但是它对于生成具有可读性的身份标识来说却是必需的。如果这种方式生成的标识会在将来继续使用,而工作流也是可能的,那么添加一个额外的阶段来保证身份标识的质量是值得的。

通常将一些用户输入作为实体属性,这些属性可用于对象匹配,但并不将这样属性作为唯一身份标识。
简单属性可作为实体状态的一部分, 他们更容易修改,在这种情况下,我们需要考虑另外的方法来生成实体的唯一标识。

3.1.2 应用程序生成唯一标识

很多可靠方法可自动生成唯一标识,但若应用程序处于集群环境或分布在不同计算节点,就要注意了!
有些方法可以生成完全唯一的标识,比如UUID或者GUID。
以下是生成唯一标识的另一种方法,其中每一步生成的结果都将添加到最终的文本标识中:

  1. 计算节点的当前时间,以毫秒记
  2. 计算节点的IP地址
  3. 虚拟机(Java)中工厂对象实例的对象标识
  4. 虚拟机(Java)中由同一个随机数生成器生成的随机数

以上可产生一个128位唯一值,可通过一个32字节或36字节的16进制数的字符串表示。在使用36字节时,可用连字符-来连接以上各步骤生成结果,比如f36ab21c- 67dc-5274-c642-lde2f4d5e72ao在不用连字符时,即为32字节。但这都是一个很大的唯一标识,且不具可读性。
在Java里,以上方法被标准的UUID生成器所替代(自从Java 1.5),对应java.util.UUlD类。该类支持4种不同的唯一标识生成算法,这些算法都基于Leach-Saiz变量。使用JavaSE API,可简单生成伪随机的唯一标识: String rawld = java.util.UUID.randomUUID().toString();
以上代码使用了第4类算法,该算法采用高度加密的伪随机数生成器,而该生 成器又基于java.security.SecureRandom生成器。第3类算法采用对名字加密的方 法,它使用了java.security.MessageDigest类。我们可以通过以下方式生成一个基于名字的UUID:

String rawld = java.util.UUID.nameUUIDFromBytes( 
    "Some text'*.getBytes())
    .toString ();

还可加密所生成的伪随机数

SecureRandom randomGenerator = new SecureRandom();
int randomNumber = randomGenerator.nextInt();String randomDigits = 
    new Integer(randomNumber).toString();
MessageDigest encryptor = MessageDigest.getlnstance(nSHA-l"); 
byte[] rawIdBytes = encryptor.digest(randomDigits.getBytes());

接下来将 rawIdBytes 数组转换成16进制数的字符串表示即可。可先将随机数转换成字符串类型,再将该字符串传给UUID的nameUUlDFromBytes。工厂方法。

UUID是一种快速生成唯一标识的方法,它不需要与外界交互,比如持久化机制。即便需要在1秒钟之内多次创建实体,UUID生成器也可应付。对有性 能要求的领域来说,可缓存UUID实例,使其在背后不间断地向缓存中填入新UUID值。如果缓存中的UUID实例由于服务器重启而丢失,在不同唯一标识间不会存在缺口,因为所有标识都是随机,因此重新向缓存中填UUID值并不会对系统造成影响。

对于如此大的唯一标识,从内存使用角度看可能不实际。可采用由持久化机制生成的8字节长标识或甚至4字节长标识就够了。

通常并不会在用户界面上显示UUID: f36ab21c-67dc-5274-c642-lde2f4d5e72a,若UUID可隐藏或可使用可读性的引用技术,那便可使用完整UUID。
比如,可通过E-mail或其他消息机制发送具有URI的超媒体资源。此时,超媒体链接中的文本部分便可以用于隐藏UUID,就像 HTML中<a>text<a>里的text。
根据UUID能够表达实体的唯一程度,可只使用UUID的一部分标记实体。在聚合(10)边界内,可将缩短后的标识作为实体的本地标识。

本地标识表示在同一聚合中,一个实体的标识只需和该聚合中的其他实体区分即可。
Aggregate(聚合)是一组相关对象的集合,作为一个整体被外界访问,聚合根(Aggregate Root)是这个聚合的根节点。聚合根(Aggregate Root)的实体则需要全局的唯一标识

对于自己创建的标识生成器,依然可用UUID的某部分。 比如对于APM-P-08-14-2012-F36AB21C,该25字节的标识表示在敏捷项目管理上下文(APM)中创建的一个Product,创建时间为2012年8月14日。额外的F36AB21C唯一标识
即为UUID的第一部分,该部分用于区分同一天所创建的不同Product。
这样的标识

  • 满足可读性要求
  • 又提供很好的全局唯一性

用户并非唯一受益者,当这样的标识从一个限界上下文传到另一个时,开发者可立即识别实体源头。对于SaaSOvation来说,还可以向标识中加入租户信息。将这样的标识作为String来维护并不是一个好办法,此时使用一个值对象更加合适:

String rawId = "APM-P-0 8-14-2012-F36AB21C" ;
// 即将生成 Productld 
productld = new Productld(rawld);
Date productCreationDate = productld.creationDate();

客户可询问标识的细节信息,比如一个Product的创建时间,就已包含于标识。客户无需知道原始的标识格式,此时聚合根Product可通过creationDate方法向外界暴露该Produc啲创建时间,而客户并不 需要知道对创建时间的获取细节。

public class Product extends Entity {
    private ProductId productld;
    ...

    public Date creationDate() {
        return this.productld().creationDate();
    }    
    ...
}

也可通过第三方类库框架来生产实体的唯一标识。比如Apache Commons的Commons Id组件,该组件提供了5种标识生成器。
有些持久化存储,比如Redis也可生成唯一标识。

对于程序生成的标识来说,什么样的对象可以作为创建标识的工厂对象呢? 对于聚合根的唯一标识,我们可以采用资源库来生成唯一标识:

public class HibernateProductRepository implements ProductRepository (
    public Productld nextidentity() {
        return new Productld(
            java.util.UUID.randomUUID()
                .toString()
                    .toUpperCase());
    }
}                

将唯一标识的生成放在资源库中是一种自然的选择。

持久化机制生成唯一标识

若从DB获取一个序列值(Sequence)或递增值,结果总是唯一。根据标识所需范围,数据库可生成2字节、4字节和8字节的唯一标识。在Java中的这些大小整数分别可表示

  • 32,767
  • 2,147,483,647
  • 9,223,372,036,854,775,807

种不同标识值。

缺陷

性能。
从DB获取标识比APP生成慢得多。一种解决方法是将数据库序列缓存在APP,比如缓存在资源库。
这固然是一种好方法,但若服务器节点需重启,那么将失去很大一部分标识值区间。若丢失区间无法接受或只需相对较小标识值(2字节整数),这缓存机制便不实用,也没必要。当然可以找回丢掉的标识值区间,但可能引入新麻烦。
如果可使用延迟生成,那缓存标识便不是问题。以下是如何使用Hibernate和Oracle的序列来生成标识:

<id name="id" type="long" column="product_id"> 
    <generator class="sequence">
        <param name="sequence">product_seq</param>
    </generate>    
</id>    

在采用MySQL的自增列时配置如下

<id name="id" type="long" column="product_id"> 
    <generator class="native"/>
</id>    

这种方式的性能是很好的,同时配置Hibernate映射也是简单的。

3.1.3 另一个限界上下文提供唯一标识

若另一个限界上下文用于给实体标识赋值,那需要对每个标识进行查找、匹配和赋值。

最重要的是精确匹配。此时用户需提供一或多种属性,比如账户、用户名和E-mail地址,以精确定位需要匹配的结果。
通常匹配的输入是模糊的,导致多个查询结果,此时用户需要手动选择,如图

  • 从外部系统中获取需要查找的唯一标识。用户界面中可显示唯一标识(本图),也可不显示

用户输入了模糊查找信息,通过调用外部限界上下文的API,返回的结果可能是0、1或多个匹配对象。接着用户要在结果中选择某特定对象。所选对象的身份标识将作为本地标识。外部实体的一些额外属性也可能被复制到本地实体。

缺陷

对象同步可能是个问题。外部对象的改变将如何影响本地对象?如何知道所关联的对象已经改变了呢?
可通过事件驱动架构领域事件解决。本地限界上下文订阅外部系统中的领域事件,当本地上下文接收到外部系统的事件通知时,它将相应更新本地对象。有时同步事件可能由本地上下文发出,外部系统在接受到该事件时同样会做相应的更新操作。
要达到这样的目的并不容易,但这样做能够创建出更加具有自治性的系统。可将对象查找限定在本地对象中。这并不是说将外部对 象缓存在本地系统中,而是将外部概念翻译成本地限界上下文中的概念。
这是最为复杂的标识创建策略。要维护本地实体,我们不但需要考虑由本地 领域行为所导致的改变,还需要将外部系统也考虑在内。所以在使用这种策略时,应持保守态度。

参考

  • 《实现领域驱动设计》