Is a guid as identity field better in domain-driven design?

Question

Is it easier to implement domain-driven design when using guids as identity fields instead of auto incrementing integers? With guids you don't have to jump to the database to get the actual value.

Jaela

The identifier of an entity and it's primary key in the database are mutually exclusive concepts IMO. A PK is an implementation detail; the domain shouldnt have any dependency on nor knowledge of the persistence layer. If you accept that, then a point in the chosen answer makes more sense. The entity identifier can be a guid set by the domain while the PK can be an auto incremented int. – Krasnoff

In terms of abstracting the persistence implementation from the domain, ask yourself this: if you were to switch your database to a flat file store, could you still get an ID from the flat file? If your answer is no, then you can see why you shouldn't use it. By allowing the domain to set the Entity's identifier (in this case, a guid), you reserve that concept for the domain. Allow the database to also generate a PK (in this case, an int) on which it can index; which is again, an implementation detail. – Krasnoff

Answer 1

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

Convector

I don't think it's so much about 'knowing the ID before it's stored' so much as it is that the domain should be the one setting the ID as the entity's identifier should be a domain concern. A PK is an implementation detail of a database, something that the domain knows nothing about. An ID that is simply an incremented integer much like an identity in a database is a coincidence. I think the two concepts need to remain separate in DDD – Krasnoff

If I'm publishing an event message in the same transaction, I might need to reference the identity of an aggregate root. – Spoke

Answer 2

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)

Efficient

Answer 3

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.

Roomer

Answer 4

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.

Tilth

Answer 5

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.

Progestin

Answer 6

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.

Procurer

I think this is completely backwards. A guid is the polar opposite of an implementation detail; A PK would be an implementation detail. It is stated many times in DDD that an entity's identifier should be a globally unique identifier. Whether or not that is used as the PK in the database is a different matter. – Krasnoff

@Krasnoff then better think again. Identity can be a relevant domain concept, its implementation is not – Procurer

I'm not even sure what that even means. The identifier is whatever the domain expert wants it to be; whether it is a guid or an int or a string is irrelevant. The one thing it should NOT be is anything that ties it to the database like an auto-incremented int, because the database IS an implementation detail. A guid is just a value, not an implementation detail. – Krasnoff

Furthermore, In your domain, you'll want an object that is an entity object, not a value object. In the entity object, you will have the identifier which is what the OP is asking about. – Krasnoff