DDD Including DB Id in domain entity

Question

According to the book, The domain layer should be isolated. In domain entity, you should avoid adding a property represents database PK (usually identity surrogate column called ID).

There is no problem in identifying a domain entity because by definition it includes a natural key. If this key is the same as PK, then repository will have no problem in persisting the domain entity using PK. Otherwise, the repository will need to construct a SQL command that find the entity based on some column(s) instead of PK.

Allowing PK to be in domain layer is the perfect approach by book, however I cannot see risky practical issues. On the other hand, without this approach, the saving process for an aggregate might lead to a performance issue in saving.

I can see only one practical problem which is "the wrong guidance for other developers". Do you know other practical problems for this approach?

Answer 1

In many cases, you want "the" primary key to be part of the domain model.

The context for this is race conditions when you have concurrent attempts to create the same entity. To prevent lost update issues, you need a design by which "first writer wins". That will usually mean that you will want the same key for both inserts, which is challenging when the database is generating a unique key for each insert.

So you still use a surrogate key - but it's a hash generated by the model, rather than an incrementing counter created by the database.

(You might also include an identifier produced by your database; but that's an implementation detail that the domain model can be ignorant of).

In a design where you don't need to worry about concurrent writes to the database (imagine having a single actor responsible for all creates), then you might have other choices. Keep in mind your fail over scenarios! If you end up with multiple instances of your actor running, then concurrent creates are a possibility again.