在領域驅動設計中，身份領域更好嗎？

Question

使用guid作爲標識字段而不是自動遞增整數時，實現域驅動設計更容易嗎？使用guid，您不必跳到數據庫即可獲取實際值。

Answer 1

好，GUID是容易，看起來像最合適的。他們很喜歡前程序員，因爲他們不必處理數據庫。另一方面，當我們在使用數據庫時不考慮數據庫問題的潛在缺點時，我會盡可能地提醒他們。

問題的確是：你真的需要在存儲在數據庫之前知道實體的ID嗎？真？ 爲什麼？

如果你決定去與最終的GUID，如果你使用SQL Server作爲後端數據庫（我不知道有足夠的瞭解其他RDBMS做出明智的建議），我會強烈建議您絕對確保GUID是而不是被用作表上的集羣密鑰。這會扼殺你的表現 - 毫無疑問。

如果確實使用GUID作爲主鍵，請確保使用別的東西，其他一些列對數據庫造成的破壞不會很大，因爲您的集羣鍵 - INT IDENTITY是我的第一選擇。

退房由金佰利特里普這些文章爲什麼一個GUID絕對不是一個好主意，因爲在SQL Server數據庫中的聚集鍵 - 她是最終的大師，當談到索引和性能問題的索引和她能使得這些點好多比我以往任何時候都可以：

• GUIDs as PRIMARY KEYs and/or the clustering key
• The Clustered Index Debate Continues...
• Ever-increasing clustering key - the Clustered Index Debate..........again!

Marc

Answer 2

我推薦Guids，因爲你不知道你在看什麼。另外，我知道這會被當成一個笑話，但我必須調試系統中發生的一個問題，它在尋找uint而不是guid。這會導致Sharepoint中的模板被停用，導致我們無法重新激活它。花了2天時間來發現潛在的問題。所以要回顧Guid's。

Answer 3

我看到GUID在遞增整數上的唯一優點是身份創建的分散。也就是說，遞增整數需要原子增量和讀取共享值，而GUID可以獨立創建，幾乎不用擔心碰撞。

至於你的建議，GUID允許在不諮詢數據庫的情況下解引用一個實體，我不明白這是怎麼回事，如果沒有其他信息沒有在你的問題中提到。您在這裏選擇的是類型之一，而不是是否使用密鑰。如果您手中有密鑰，並且密鑰通過數據庫映射到值或實體，則需要查閱數據庫以解密引用密鑰。

Answer 4

我使用GUID的原因有兩個：

• 的ID是唯一的，不僅在那裏它被創建的上下文中，所以ID的相同類型的數據可以在不同的位置產生。如果您有多個分佈在不同地理位置的互相交換數據或處於斷開連接的情況下的安裝情況，則這種做法很好。
• 它反駁了以邏輯方式處理ID的衝動，而是強制開發人員將該值視爲「公正和ID」。

但是，我不一定會說這些參數僅適用於域驅動設計。

Answer 5

DDD的核心原則之一是持久性無知。所以，是的，GUID是最簡單的方式，無需依賴持久性存儲即可爲您的對象提供唯一標識。

注：如果您使用的GUID很關心數據庫的性能，可以考慮使用梳子（專爲SQL Server索引碎片）

Answer 6

不，絕對不是。 GUID是不應該泄漏到您的域中的實現細節。你需要一個身份值對象，我不在乎你如何實現它。