0
我們有兩種不同的微服務客戶服務和訂單服務。關於顧客的顧客服務店信息,例如姓名,出生日期等。訂單服務將管理顧客具有的訂單,即訂單號,成本等。這是將顧客唯一參考/ ID傳遞給訂購服務的最佳方式。微服務傳遞實體id guid或唯一代碼
解決方案1: 客戶ID是唯一在客戶服務中的GUID。這將被傳遞給訂購服務
解決方案2: 生成業務/對人友好的獨特的客戶服務代碼,並把它傳遞給訂購服務
解決方案3: 別的東西嗎?
我們有兩種不同的微服務客戶服務和訂單服務。關於顧客的顧客服務店信息,例如姓名,出生日期等。訂單服務將管理顧客具有的訂單,即訂單號,成本等。這是將顧客唯一參考/ ID傳遞給訂購服務的最佳方式。微服務傳遞實體id guid或唯一代碼
解決方案1: 客戶ID是唯一在客戶服務中的GUID。這將被傳遞給訂購服務
解決方案2: 生成業務/對人友好的獨特的客戶服務代碼,並把它傳遞給訂購服務
解決方案3: 別的東西嗎?
我會建議你第一個選項。它與其他上下文中使用的Id相同,這樣您就不需要創建僅用於共享引用的內容。
第二,是否有任何背景原因,你不會分享真正的Id,而是一個生成的密鑰?如果是的話(你對此沒有提及),那麼第二個會更好,因爲你「保護」了你不想分享的東西。這需要一種方式,在CustomerMicroservice上,從生成的密鑰中獲取用戶(如果需要的話)。
編輯:
隨着「理由」我的意思不是說要求標識的操作(這將是一個有點怪怪的),但是,例如,用戶需要訪問這些信息用於與呼叫中心進行交互。在這種情況下,人們可讀的值比Guid好得多。
如果您使用人性化的ID,那麼您需要一個由人類生成+檢查它們的過程;這是值得的? –
可能值得使用包含「CustomerID」和「CustomerName」/「Description」的值對象來簡化操作。 YMMV –
@EbenRoux只要你不試圖保持同步並將它們視爲值。 – plalx