8

The best example would be an User entity which needs to be persisted. I have the following candidates to assign unique identifier to an user:

  1. Assign keys provided by back-end (NDB, MySQL etc.).
  2. Hand crafting unique identifier through some service (like system clock).
  3. Properties like emailId.

Taking a simple example of a detailed view, we often have a detailed display of an user like some/path/users/{user_id}, if we keep emailId as the unique id then there are chances that an user may change its email id one day and breaks it.

Which is a better approach to identify the same entity?

vivek
  • 2,807
  • 5
  • 31
  • 44
  • 1
    Possible duplicate of [Domain Driven Design Auto Incremented Entity Key](http://stackoverflow.com/questions/34315605/domain-driven-design-auto-incremented-entity-key) – theDmi Feb 19 '16 at 09:16
  • Depending on your requirements, all three of the presented choices could be considered to be "good strategy". – Cerad Feb 19 '16 at 11:57

2 Answers2

6

Named UUID.

UUID, because it gives the identifier a nice predictable structure, without introducing any semantic implications (like your email id example). Think surrogate key.

Named UUID, because you want the generated id to be deterministic. Deterministic means reproducable : you can move your system to a test environment, and replay commands to inspect the results.

It also gives you an extra way to detect duplicated work - what should happen in your system if a create user command is repeated (example: user POSTs the same web form twice). There are various ways that you can guard against this in your intermediate layers, but a really easy way to cover this in your persistence layer (aka in your system of record) is to put a uniqueness constraint on the id. Because running the command a second time produces a "new" user entity with the same id, the persistence layer will object to the duplication, and you can handle things from there.

Thus, you get idempotent command handling even if all of your intermediate guard layers restart during the interval between the duplicated commands.

Named UUID gives you these properties; for instance, you might build the uuid from an identifier for the type of the entity and the id of the command (the duplicated command will have the same id when it is resent).

You can use transient properties of the user (like email address) as part of the seed for your named uuid if you have a guarantee that the property won't ever be assigned to someone else. Are you sure vivek@stackoverflow.com won't be assigned to another user? Then it's not a good seed to use.

Back end key assignment won't detect a collision if a command is duplicated - you would need to rely on some other bit of state to detect the collision.

System clock isn't a good choice, because it makes reproducing the same id difficult. A local copy of the system clock can work, if you can reproduce the updates to the local clock in your test environment. But that's a bunch of extra effort your don't want if time isn't already part of your domain model.

Community
  • 1
  • 1
VoiceOfUnreason
  • 52,766
  • 5
  • 49
  • 91
1

I agree with @VoiceOfUnreason but only partially. We all know that UUIDs are terrible to spell and keep track of. All methods to use incremental and meaningful UUIDs resolve only parts of these issues.

An aggregate is being created with some id that is already available to the creating party. Although UUID can be generated without involving any external components, this is not the only solution. Using an external identity provider like Twitter Snowflake (retired) is an option too.

It is not very complicated to create very simple and reliable identity provider that can return incrementing long value by being given an aggregate type name.

Surely, it increases the complexity and can only be justified when there is a requirement to generate sequential unique numeric values. Resilience of this service becomes very important and needs to be addressed carefully. But it can just be seen as any other critical infrastructure component and we know that every system has quite a few of those anyway.

Alexey Zimarev
  • 17,944
  • 2
  • 55
  • 83