DDD: Primary keys (Ids) and ORMs (for example, NHibernate)

Question

Why is it considered OK to have an Id field in the domain entities? I have seen several solutions that provide base class with Id and Id-based GetHashCode/Equals.

My understanding of domain model is that it should contain only things related to the domain. While in rare cases (trackable orders) Ids are meaningful, most of the time they do not provide anything except a simple way to reference objects in DB/on UI.

I do not see a Equals/GetHashCode benefits either, since the Identity Map implementation should guarantee that reference equality is the id equality anyway.

Strangely, I can not easily find what other people think on this subject, so I am asking it here. What is the general opinion on using non-domain related Ids in the domain entities? And are there any problems with NHibernate if I do not add Ids to my domain entities?

UPDATE:

Thanks for the answers.

Several of them suggest that having Id is the only way for the ORM to do a DB update. I do not think this is the case. ORM already keeps track of all entities loaded from the DB, so it should be easily able to get an Id internally when it needs one.

UPDATE 2:

Answer to Justice and similar points: What if we have a web application and need a way to reference the entity between sessions? Like edit/resource/id?

Well, I see this as a specific need of the constrained UI/environment, not a domain model need. Having an application service or repository with GetIdentitity method (consistent with Load(identity) method) seems to be enough for this scenario.

Answer 1

I know this is a reaaaaally old post, but I stumbled on it while searching for some Domain Driven Design patterns and saw that this post could need another point of view not mentioned here for all the people who ask themselves OPs question:

Why is it considered OK to have an Id field in the domain entities?

Well, lets see what is considered an Entity:

Domain-driven design recognizes multiple kinds of models.

For example, an entity is an object defined not by its attributes, but its identity.

Quote from https://en.wikipedia.org/wiki/Domain-driven_design

So if your Business Object is an Entity it has to have an id that is immutable and globally unique. That is why business entities need an Id. On the other hand there are value objects, which by definition are identified by the values of their attributes. So they do not need a distinct id.

So why do in many models people write Ids to all their business classes? Usually to save them in the database which leads us to completely different topic: Persistence.

And in this case OPs feeling that putting an id into every business class feels wrong is correct. It is just bad application architecture design that leaks implementation details (how to persist data) into the domain model (by using primary keys in business classes).

So my answer: There are a lot of Ids in business objects because people do not separate their domain from their implementation thus keep mixing both. It is just bad application design. I personally think this comes from the heavy usage and misconceptions of the usage of ORMs. They make it easy to bring your database scheme to your OOP application but often people misuse it, might it be, because they do not know better or because it is just easier operate on the database objects given from an OR-mapper (the latter is often seen together with other common anti patterns like anemic domain model, mutable objects and / or spreading business logic across the application like putting it into controllers or even worse into the OR-mapping types).

So my answer to the question:

So why do in many models people write Ids to all their business classes?

Together with your statement:

My understanding of domain model is that it should contain only things related to the domain.

is as follows: An id (as an Identity) is via definition mandatory for an Entity in DDD but must not be provided to value objects, whose identity is defined by their attributes.

And my advice for people struggling with DDD and OR-mappers (Hibernate, EntityFramework[Core], you name it): Separate your Business Model from your Database Model. In fact these two correlate a lot, but they are definetly not the same. Do not put business logic into your database model. Put it where it belongs: In methods of your Business Classes (which gives them behavior) or in your application services that operate on your business objects and use the OR-mapper as what it was meant for: mapping Data to OOP Objects. That also prevents the anemic domain model anti pattern. A good separation of business model and implementation makes it by the way possible to switch to another implementation.

Links and more information about DDD:

Vaugn Vernon - Domain-driven design distilled (ISBN-10: 0134434420; ISBN-13: 978-0134434421)

https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html

https://en.wikipedia.org/wiki/Domain-driven_design

https://en.wikipedia.org/wiki/Anemic_domain_model

https://www.yegor256.com/2014/12/01/orm-offensive-anti-pattern.html

Answer 2

I just can talk about NHibernate. There you need a field for the primary key, it's up to you if you take business data (not recommended) or a surrogate key with no business meaning.

Typical scenarios are:

• auto-incrementing value generated by the database
• guid generated by NHibernate
• guid generated by the business logic

There is a big advantage to have a unique id. When you pass your object around, for instance to the client and back to the server, you can't rely on memory identity. You could even have several instances in memory of the same business instance. The business instance is identified by the id.

Id-based comparison is a matter of taste. Personally I like simple and reliable code, and id-based comparison is simple and reliable, while deep-comparison is always a bit risky, error-prone, unmaintainable. So you end up with operator == comparing the memory identity and Equals comparing the business (and database) identity.

NHibernate is the less intrusive way to map a class model to a relational database I know. In our large project we have primary keys and version properties (they are used for optimistic locking). You could argue that this is intrusive, because it is not used for the business logic.

NH doesn't require to have these properties. (however it needs one of the properties as primary key.) But consider:

• It just works better, eg. pessimistic locking is only possible with a appropriate property,
• faster: int id's perform better on many databases then other data types
• and easier: taking properties with a meaning to the business are discouraged for several reasons.

So why making your life harder than necessary?

---

Edit: Just read the documentation and found that NHibernate does not need an id property in the persistent class! If you don't have an indentifier, you can't use some features. It is recommended to have it, it just makes your life easier.

Answer 3

In Nh, you can't use reference equality for detached instances. This stuffs you for using NH in clients that would like to use this behaviour (in my opinion this is the correct behaviour, NH doesn't depend on magic!) .

In web apps or session based usages where you can go to the db in the scope of one ISession, I think I am correct in saying you can rely on reference equality. But in a smart client scenario, or more specifically, any scenario in which two ISessions are sharing an instance (one loaded from or inserted into the db, then passed to the second), you need the db id field(s) stored along with the instance.

the second session below would no idea that the instance that it is being passed is has already been inserted and requires an update, and even if you changed it to an update, I assume I am right in thinking it is not going to know the DB ID of the class.

class SomeEntityWithNoId
{
public  blah etc {}
}

class dao
{

void DateMethod()
{
var s1 = sessionFactory.OpenSession();
var instance = new SomeEntityWithNoId();
instance.Blah = "First time, you need to insert";
s1.Save(s1); //now instance is persisted, has a DB ID such as identity or Hilo or whatever
s1.close();
var s2 = sessionFactory.OpenSession();
s2.Blah = "Now update, going to find that pretty hard as the 2nd session won't know what ID to use for the UPDATE statement";

s2.Update(instance); //results in boom! exception, the second session has no idea *how* to update this instance.




}
}

If you are concerned about the ID field(s), which you are correct in thinking is largely useless for anything other than persistence concerns, you can make them private, so at least this behaviour and semantics are encapsulated. You might find that this approach puts some friction into TDD.

I think you are correct about the ID maps with regards to NH at least. If the instance is transient when it is first attached to the session, your type does not need to store its db ID in a field. I think the session will know how to manage it's relationship with the db. I'm sure you can bust out a test to prove this behaviour ;p

Answer 4

Typically, you will not have the one true domain model. You will have innumerable concurrent and sequential sessions, which must be coordinated, and each of which contains within it its own miniature, isolated, transactional domain model. You will not have the same object instances between two concurrent or between two sequential sessions. But you will need some way to ensure that you can move information from one session to another.

An example, of course, is a /resource/list and /resource/show/id pair of URL's (corresponding to an appropriate pair of controller actions in asp.net mvc). Moving from one to the other, there are two completely independent sessions, but they need to communicate (through HTTP and the browser) with each other.

Even without using a database, your domain model objects will still need some form of identity because you will still have numerous miniature, isolated domain models, not the one true domain model; and you will have all these domain models in independent sessions both at the same time and one after another.

Object sameness does not suffice, because objects are not the same between sessions even though the underlying conceptual entities which they represent are the same entity.

Answer 5

assuming that your id is your primary key, you will not be able to save any data back to the DB without it.
As far as equals and GetHashCode go, these are for ordering in Lists where you create a custom ordering.

Thanks for the answers.

Several of them suggest that having Id is the only way for the ORM to do a DB update. I do not think this is the case. ORM already keeps track of all entities loaded from the DB, so it should be easily able to get an Id internally when it needs one.

I would be very surprised if that were the case. Usually it creates an insert statement only from the properties you've defined.

Answer 6

There are no other option to get the same object without identity. For example people have social security number or personal code or something that is unique and we can identify them by it.

You might use natural identity but that is error prone.

Just rename Id to Identity. It looks nicer in domain model.

Entities are called entities because they have identity.

Answer 7

You could also use multiple fields to establish identity, called composite keys. This will require more work on your end, however.

Learn about them here

Answer 8

I typically include the Id in the domain as a base Entity class. I don't know of any other way to use an ORM.

An object in the domain is already unique by its reference, using an id to determine uniqueness/equality isn't really that different in practice. I haven't encountered a serious side effect to this approach so far.

Answer 9

You have to have it one way or another so the ORM can go back to the database to perform updates; I guess it could be private and hidden in a base class but that kinda violates the POCO concept.