Unique Identity

Value Objects

Value Objects can serve as holders of unique identity.
They are immutable which ensures identity stability and centralize any behavior.
They also provide the benefit of being a Strongly Typed Identifier.

Identity Creation Strategies

User Provides Identity

A simple approach with complications.
Can users be relied upon to produce both unique and correct, long-lasting identifies?
We always have the option of user-provided values as Entity properties available for matching but NOT used for unique identity.

Application Generates Identity

Highly reliable
A GUID or UUID is a common approach to identity creation that can produce a completely unique identity.
We don't normally want to display a UUID in a UI. UUID is appropriate when it can be hidden from users and human-readable reference techniques can be used.
Parts of a the generated UUID can be used with other attributes to generate a human-readable identifier.
- TIP: Encapsulate this logic in a custom identity Value Object.

Persistence Mechanism Generates Identity

Provides unique advantages
Calling the database for a sequence or incrementing value ensures uniqueness.
Downside: Performance
- Takes longer to go to the database to get each value vs. an application-generated Identity.
- Can potentially be mitigated through caching, but that requires more implementation and potential gaps between identities.

Another Bounded Context Assigns Identity

An exact match between the local Entity and the remote Entity is the most desirable.
If the local context uses state from the remote context, we need to synchronize.
- This is solved using Event Driven Architecture + Domain Events.
- This leads to more autonomous systems.
- Important: This is not about caching foreign objects locally. Instead, it involves translating foreign concepts into those of the local Bounded Context.
- Use this approach conservatively.

PreviousWhy We Use Entities Next6: Value Objects

Last updated 1 year ago

Identity Creation Strategies

User Provides Identity

A simple approach with complications.

Can users be relied upon to produce both unique and correct, long-lasting identifies?

We always have the option of user-provided values as Entity properties available for matching but NOT used for unique identity.

Application Generates Identity

Highly reliable

A GUID or UUID is a common approach to identity creation that can produce a completely unique identity.

We don't normally want to display a UUID in a UI. UUID is appropriate when it can be hidden from users and human-readable reference techniques can be used.

Parts of a the generated UUID can be used with other attributes to generate a human-readable identifier.

TIP: Encapsulate this logic in a custom identity Value Object.

Persistence Mechanism Generates Identity

Provides unique advantages

Calling the database for a sequence or incrementing value ensures uniqueness.

Downside: Performance

Takes longer to go to the database to get each value vs. an application-generated Identity.
Can potentially be mitigated through caching, but that requires more implementation and potential gaps between identities.

Another Bounded Context Assigns Identity

An exact match between the local Entity and the remote Entity is the most desirable.

If the local context uses state from the remote context, we need to synchronize.

This is solved using Event Driven Architecture + Domain Events.
This leads to more autonomous systems.
Important: This is not about caching foreign objects locally. Instead, it involves translating foreign concepts into those of the local Bounded Context.
Use this approach conservatively.