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?

• MBouallegue: One problem can be when you rely on the auto increment id of the database. Because then you wont be able to create a new instance of an aggregate root without calling the db. And you can find yourself forced to persist an aggregate while it is in an invalid state.
• guillaume31: Possible duplicate of softwareengineering.stackexchange.com/questions/235254/…
• Bart van Ingen Schenau: Possible duplicate of ID properties on Domain objects in DDD

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.

• Flater: The protection for concurrent writes can easily be upheld by a unique constraint on the non-PK natural key column. It does not have to be a PK for this.