Identity conflict in DDD with Repository

Question

I'm following a database first approach in a sample app. The POCO classes are generated via t4 template and it will have the Identity properties that it carry from the database. For some classes which I use as entities in the domain, the type of the id can be int, string & Guid.

I don't see a problem with ids that are string or Guid which I can generate in the domain and pass that to the repository. In the case of int also I can do that, but I want to take advantage of the AUTOINCREMENT option of the SQL Database.

My questions are:

1. Who's responsibility is to generate the Identity for the Entity. Is it the domain or the repository?

2. How the syncing of identities can be done between the repositories and the domain? For example, I can create an id of 1000 for a Customer in the domain, and ask the Repository to save it. When the repository saves it, the new identity may be 2000 (the AUTOINCREMENT option sets the new identity). Now the two entities are different, and if the Customer entity in the domain (assume it is cached for future operations) is used with other entities like Department, it can cause problems in the domain. The cached entity (Customer) in the domain which has the id of 1000 will be saved as a new entity in the SQL datastore. The repository does not know whether the Customer is cached or new.

Answer 1

Who's responsibility is to generate the Identity for the Entity. Is it the domain or the repository?

The identity of an entity can be assigned by the domain either directly or via client request. This type of identity is usually generated with a Guid or another universally unique value. The identity can also be assigned by the repository to reflect a database generated identity such as an incremental identity column.

How the syncing of identities can be done between the repositories and the domain?

When an entity's identity is sourced from a database generated identity column, the domain should not assign its own identity. A transient entity with an integral identity will initially have identity value 0. When the transient entity is made persistent, the repository will assign the identity value. At that point, as you point out, there may some issues with cached instances of the newly persistent entity instance since the identity value has changed. There are a few ways to resolve these issues, but I try to avoid referencing transient entities in caches (or anywhere else) in the first places. This can be more easily done by making sure an entity isn't referenced in many places until it is made persistent. If you do end up referencing a transient entity instance in various places, you can make sure that its .NET runtime identity remains the same for the lifetime of the instance. To do this, you have to compare entities via object.ReferenceEquals before the identity value check and you have to cache the hash-code generated via GetHashCode for the duration of the object lifetime.