DDD領域驅動設計實戰 - 建立實體身份辨別的常用政策（上）

從簡單到複雜依次為：

3.1.1 使用者提供唯一辨別

這時使用者将輸入一些可識别的數值或符号，或從已有辨別中選其一，然後建立實體對象。這是一種非常簡單方案，但也可能變得複雜。

由于需使用者自己生成高品質的辨別。是以辨別可能唯一，卻有可能是不正确的。

缺陷

多數情況下辨別不可變，使用者無法修改辨別。但有時賦予使用者修改辨別值的權限有好處。

例如，若将Forum和Discussion的名字作為唯一辨別，那麼發生拼寫錯誤時怎麼辦，或使用者之後想采用新名字怎麼辦？

• Forum名字拼寫錯誤，Discussion名字長度小于所要求的

• 

• 要改變這些辨別值需要多大代價？雖然使用者提供的身份辨別看似一種節約成本的做法，但也有可能不是。此時我們還可以依賴使用者來提供唯一的、正确、穩定的對象辨別嗎？

為避免上述問題，需重新設計。開發需采用無故障的方法來保證使用者輸入的确是唯一的身份辨別。雖然基于工作流的辨別審批過程，對于高吞吐量的領域并無多大幫助，但是它對于生成具有可讀性的身份辨別來說卻是必需的。如果這種方式生成的辨別會在将來繼續使用，而工作流也是可能的，那麼添加一個額外的階段來保證身份辨別的品質是值得的。

通常将一些使用者輸入作為實體屬性，這些屬性可用于對象比對，但并不将這樣屬性作為唯一身份辨別。

簡單屬性可作為實體狀态的一部分， 他們更容易修改，在這種情況下，我們需要考慮另外的方法來生成實體的唯一辨別。