Well, GUIDs are easy and look like the best fit. They re tempting to frontend programmers, since they don t have to deal with the database.

On the other hand, when looking at the potential drawbacks they have when used without thinking about database issues too much, I would warn against them as much as possible.

The question really is: do you really need to know the ID of the entity before it s stored in the databsae? REALLY? WHY?

If you do decide to go with GUIDs in the end, and if you re using SQL Server as your database backend (I don t know enough about other RDBMS to make an informed suggestion), I would strongly recommend you make absolutely sure that the GUIDs are not being used as the clustering key on the tables. This will kill your performance - no doubt.

If you do use GUIDs as your primary key, make sure to use something else, some other column that wrecks less havoc on your database, as your clustering key instead - a INT IDENTITY would be my first choice.

Check out these articles by Kimberly Tripp on why a GUID is definitely not a good idea as a clustering key in a SQL Server database - she s the ultimate guru when it comes to indexing and performance issues with indexing and she can makes those points much better than I ever could:

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

Marc

One of the core tenets of DDD is Persistence Ignorance. So yes, GUIDs are the easiest way to provide your objects with unique identity without having to rely on a persistence store.

NB: If you re concerned about database performance using GUIDs, consider using COMBs (specifically for SQL Server index fragmentation)

I recommend Guids as there is no confusion as to what it is you are looking at. Also, and I know this gets tossed around as a joke a lot, but I had to debug an issue that happened in the system where it was looking for uint s instead of guids. This caused a template in sharepoint to be deactivated and gave us no way to reactivate it. Took 2 days to discover what the underlying issue was. So to recap go with Guid s.

The only advantage I see to GUIDs over an incrementing integer is decentralization of identity creation. That is, the incrementing integer requires an atomic increment and read of a shared value, while GUIDs can be created independently with little fear of collision.

As for your suggestion that GUIDs allow one to dereference an entity without consulting the database, I don t see how that s the case, absent some other information not mentioned in your question. Your choice here is one of key type, not whether or not to use a key. If you have a key in hand, and the key maps to a value or entity by way of the database, you need to consult the database to dereference the key.

I use guid s for two reasons:

• The ID is unique not only within the context where it is created, so ID s for the same type of data can be generated in different locations. This is good in cases where you have several installations distributed geographically that interchange data with each other, or in disconnected scenarios.
• It counter-acts the urge to treat the ID in logical ways, but rather enforces developers to regard the value as "just and ID".

However, I would not necessarily say that these arguments are valid only for domain-driven design.

No, definitely not. A GUID is an implementation detail that is not supposed to leak into your domain. You need an identity value object, and I don t care how you implement it.