Addressing the fact that primary keys are not part of your business domain

Question

In almost all circumstances, primary keys are not a part of your business domain. Sure, you may have some important user-facing objects with unique indices (UserName for users or OrderNumber for orders) but in most cases, there is no business need to overtly identify domain objects by a single value or set of values, to anyone but perhaps an administrative user. Even in those exceptional cases, especially if you are using global unique identifiers (GUID), you will like or want to employ an alternate key rather than expose the primary key itself.

So, if my understanding of domain-driven design is accurate, primary keys need not and thus should not be exposed, and good riddance. They're ugly and cramp my style. But if we choose not to include primary keys in the domain model, there are consequences:

1. Naively, data transfer objects (DTO) that derive exclusively from combinations of domain models will not have primary keys
2. Incoming DTO's will not have a primary key

So, is it safe to say that if you are really going to stay pure and eliminate primary keys in your domain model, you should be prepared to be able to handle every request in terms of unique indices on that primary key?

Put in another way, which of the following solutions is the correct approach to dealing with identifying particular objects after removing PK in domain models?

1. Being able to identify the objects you need to deal with by other attributes
2. Getting the primary key back in the DTO; ie, eliminating the PK when mapping from persistence to domain, then recombining the PK when mapping from domain to DTO?

EDIT: Let's make this concrete.

Say my domain model is VoIPProvider which includes fields like Name, Description, URL, as well as references like ProviderType, PhysicalAddress, and Transactions.

Now let's say I want to build a web service that will allow privileged users to manage VoIPProviders.

Perhaps a user-friendly ID is useless in this case; after all, VoIP providers are companies whose names tend to be distinct in the computer sense and even distinct enough in the human sense for business reasons. So it may be enough to say that a unique VoIPProvider is completely determined by (Name, URL). So now let's say I need a method PUT api/providers/voip so that privileged users can update VoIP providers. They send up a VoIPProviderDTO, which includes many but not all of the fields from the VoIPProvider, including some flattening potentially. However, I can't read their minds, and they still need to tell me which provider we are talking about.

It seems I have 2 (maybe 3) options:

1. Include a primary key or alternate key in my domain model and send it to the DTO, and vice versa
2. Identify the provider we care about via the unique index, like (Name, Url)
3. Introduce some sort of intermediate object that can always map between persistence layer, domain, and DTO in a way that does not expose implementation details about the persistence layer - say by introducing an in-memory temporary identifier when going from domain to DTO and back,

Answer 1

This is the way how we solve this (since more than 15 years, when even the term "domain driven design" was not invented):

• when mapping the domain model to a database implementation or a class model in a specific programming language, you have a simple, consistent rule like "for each domain object mapped to a relational table, the primary key is "TablenameID".
• this primary key is completely artificial, it has always the same type, and no business meaning - just a surrogate key
• the "graphical version" of your domain model (the one you use to talk to your domain experts) does not contain primary keys. You don't expose them directly to the experts (but you expose them to anyone who is actually implementing code for the system).

So whenever you need a primary key for technical purposes (like mapping relations to a database), you have one available, but as long as you don't want to "see it", change your level of abstraction to the "domain experts model". And you don't have to maintain "two models" (one with PKs and one without); instead, maintain only a model without PKs and use a code generator to create the DDL for your DB, which adds the PK automatically according to the mapping rules.

Note that this does not forbid to add any "business keys" like an additional "OrderNumber", besides the surrogate OrderID. Technically these business keys become alternate keys when mapping to your database. Just avoid using these for creating references to other tables, always prefer using the surrogate keys if possible, this will make things a hell lot easier.

To your comment: using a surrogate key for identifying records is no business-related operation, it is a purely technical operation. To make this clear, look at your example: as long as you don't define additional unique-contraints, it would be possible to have two VoIPProvider objects with the same combination of (name,url), but different VoIPProviderIDs.

Answer 2

You need to be able to identify many objects by some unique index, and isn't that what a primary key is (or at least implies one is present).

Unique indexes are available so you can further constrain your DB schema, not as a wholesale replacement for PKs. If you're not exposing PKs becuase they;re ugly, but are exposing an unique key instead... you're not actually doing anything different. (I assume you're not getting a PK and an identity column mixed up here?)

Answer 3

Without primary keys in the frontend there is no easy way for the backend to know what you are sending. To fix that you would need a ton of extra work parsing the data, which would hurt performance and probably take more time and be more ugly than attaching a key to every item.

As an example, lets say that I want to edit a message in an app; how would the app know which message I want to edit without a primary key attached? Editing objects happens all the time and doing that without keys is nigh impossible. But if you have objects that aren't supposed to be edited then skip the key if you think that it is distracting, but having primary keys can improve performance here.

Answer 4

The reason we use a non-business related PK is to ensure that our system has an easy and consistent method of determining what the user wants.

I see you replied with a comment: MessageSender, MessageRecipient, TimeSent (for a message). You can STILL have ambiguity this way (for example, with system generated messages triggering on something that happens often). And how are you going to validate MessageSender and MessageRecipient here? Suppose you validate them using FirstName, Lastname, DateOfBirth, you're going to eventually run into a situation where you have 2 people born on the same day with the exact same name. Not to mention that you will run into a situation where you have a message named tacostacostacos-America-1980-Doc Brown-France-1965-23/5/2014-11:43:54.003UTC+200. That's a monster of a name, and you still have no guarantee you'll only have 1 of those.

the reason we use a primary key is because we KNOW it'll be unique for the lifetime of the software, no matter what data is entered, and we KNOW it's going to be a predictable format (what happens if your above key has a dash in a username? your whole system goes to shit).

You don't need to show your ID to your user. You can hide that (in plain sight if necessary, through the URL).

Another reason why a PK is so useful is something you can deduce from the above: a PK makes it so that you don't have to force the computer to interpret user-generated code. If a Chinese user uses your code and enters a bunch of Chinese characters, your code suddenly doesn't need to be able to work with these internally, but it can simply use the Guid that the system generated. If you have an Arabic user who enters Arabic writing, your system doesn't have to cope with that internally, but can basically ignore that they're there.

As others have said, a Guid is something that can be stored internally in a fixed size. You know what you work with and it's something that can be universally used. You don't need to create design rules on how you create a certain identifier and save it. If your system only takes the first 10 letters of a name, it doesn't see any difference between Michael Guggenheimer and Michael Gugstein, and it will confuse these 2. If you cut it off at any arbitrary length, you can run into confusion. If you limit user input, you can run into issues with user limitations.

When I look at existing systems like Dynamics CRM, they also use the internal key (the PK) for the user to call upon a single record. If a user has a query that doesn't involve the ID, they return an array of possible answers and let the user choose from it. If there is any chance at ambiguity, they'll give the choice to the user.

Finally, it's also abit of security through obscurity. If you don't know the record ID, your only option is to guess it. if the ID is easy to guess (because the information that it's made of is publicly available), anyone can change it. You can even goad the user into changing it through classic CSRF or XSS methods. Now, obviously your security should already have those accounted for and mitigated before ever publishing the live version, but you should still make it harder for potential abuse to happen.

Answer 5

When issuing an identifier for an external system, you should only give URIs, or alternatively a key or a set of keys that have the same properties as a URI, rather than exposing the database primary key directly (from here onwards I'll refer to both URI or a key or a set of keys that have the same properties as URI as just URI, in other word a URI below doesn't necessarily mean RFC 3986 URI).

A URI may or may not contain the primary key of the object and it may or may not actually be composed of alternate keys. It doesn't really matter. What matters is that only the system that generates the URI is allowed to split or combine the URI to form an understanding of what the referred object is. External systems should always use the URI as an opaque identifier. It doesn't matter if a human user can identify that one part of the URI is actually a database surrogate key or that it consists of several business keys bunched up together, or that it's actually a base64 of those values. These are irrelevant. What matters is that the external system shouldn't need to be required to understand what the identifier means to use the identifier. External systems should never be required to parse the components within the identifier or combine an identifier with other identifiers to refer to something in your system.

Using GUID fulfills some of this criteria, however identifier like GUID can be difficult to dereference back into the object even within your system, so keys that are opaque to even your system like a GUID should only be employed if client parsing the URI/identifier actually poses a security risk.

Back to your VoIP example, say that a VoIP provider can be uniquely determined either by (VoIPProviderID) or by (Name, URL) or by (GUID). When an external system needs to update the VoIP provider, it can just pass a PUT /provider/by-id/1234 or PUT /provider/foo-voip/bar-domain.com or PUT /3F2504E0-4F89-41D3-9A0C-0305E82C3301 and your system would understand that the external system wants to update the VoIPProvider. These URIs are generated by your system and only your system need to understand that all they means the same thing. The external system should just treat whatever is in the URI as basically a PUT <whatever>.

Suppose that you have the data for different VoIP providers stored in different tables with different schemas (thus completely different set of keys identifies each VoIP provider based on which table they are stored in). When you have a URI, they can be accessed uniformly by the external system, without regards of how your system identify the particular VoIP provider. To the external system it's all just opaque pointer.

When your system uses a URI to refer to objects in such a way, you're not leaking anything regarding how you implement your system. You generate the URI and the client simply passes it back to you.

Answer 6

I am going to have to target this wildly inaccurate and naive statement:

Perhaps a user-friendly ID is useless in this case; after all, VoIP providers are companies whose names tend to be distinct in the computer sense and even distinct enough in the human sense for business reasons.

Names are terrible as keys, as they are frequently changing. A company may have many names during its lifetime, the company may merge, split, merge again, create a distinct subsidiary for specific tax purposes that has 0 employees but all customers which then hires employees from a completely different subsidiary.

Then we get into the fact that company names are not even remotely unique, as shown by the landmark Apple vs. Apple.

A good object relational mapper or framework should abstract the primary keys away and make these invisible, but they are there, and they will usually be the only way to uniquely identify an object in your database.

For reference, I prefer how django handles this:

class VoipProvider(models.Model):
    name=fields.TextField()
    address=fields.TextField()

class Customer(models.Model):
    name=fields.TextField()
    address=fields.TextField()
    voipProvider=fields.ForeignKeyField(VoipProvider)

In this way, the details of a provider of a customer can be access in code by using:

myCustomer.voipProvider.name #returns the name of the customers VOIP Provider.

While the Primary/Foreign keys aren't visible, they are there, and can be used to access items, but are abstracted away.

Answer 7

I think we often still incorrectly look at this issue from the perspective of the DB: oh, there's no natural key, so we need to create a surrogate key. Oh no, we can't expose the surrogate key back into the domain objects, that's leaky etc.

However, sometimes a better attitude is this: if a business (domain) object doesn't have a natural key, then perhaps it should be given one. This is a two-fold business domain issue: Firstly, things need an identity, even in the absence of databases. Secondly, although we try to pretend persistence is some abstract idea invisible to the domain, the reality is that persistence is still a business concept. Obviously, there are issues where the chosen natural key isn't supported by the DB as a primary key (e.g. GUIDs on some systems) - in this case you will need to add a surrogate key.

Thus, you end up in a very similar place, e.g. your customer has an integer ID, but instead of feeling ill because that has leaked from the DB to the domain, you feel happy because the business has agreed that all customers shall be assigned an ID, and you are persisting that to the DB, as you must. You are still free to introduce a surrogate, e.g. to support renaming the customer ID.

This approach also means that if a domain object hits the persistence layer, and doesn't have an ID, then it's probably some sort of value object, so doesn't need an ID.