I'm working on a Domain-Driven Design (DDD) project and I'm trying to clarify when the uniqueness of an attribute should be treated as a domain invariant versus being a technical or infrastructure concern.
Consider these two scenarios:
Business Attribute (e.g., Email): A user's login email is critical to the domain. Its uniqueness is a domain invariant because it directly affects user identification and authentication. In this case, ensuring that no two users share the same email is essential for the business logic and is often enforced via domain services or within the aggregate.
Auto-Generated Technical Identifier (e.g., Reservation ID): A Reservation entity uses an auto-generated numeric ID as its unique identifier. Although this ID is created by the infrastructure (such as an auto-incremented field in the database), it still serves as a domain invariant. This is because every entity in the domain must have a unique identity to maintain proper relationships and consistency across aggregates. Even if the mechanism of generation is delegated to the repository, the fact that each reservation must have a unique ID is a core requirement of the domain.
When should uniqueness be enforced as a domain invariant versus when it can be handled as a technical concern? Given that the Reservation ID is auto-generated but still essential for relating entities, should we consider its uniqueness as a domain invariant that the system must always guarantee?
Any insights, best practices, or references on how to manage these different kinds of uniqueness within a DDD context would be greatly appreciated.
My take on this is that the responsibility shifts away from the domain as it starts affecting sets.
At the "lowest" level we should have the aggregate handle consistency. For instance, uniqueness of value objects would be the responsibility of the aggregate, even though it could be enforced by a domain service (outside of an aggregate) or an application service (outside of the domain). We want to keep the functionality as close to an entity/aggregate, hence the domain, as possible.
Next we may have functionality that doesn't seem to fit on an entity and we end up using a domain service that spans, say, a couple of aggregates. Again, something an application service (outside of the domain) could do but we want to keep the functionality as close to the domain as possible.
Ensuring unique synthetic keys, or any other unique constraints, is not something that an aggregate root, or even a domain service, can enforce. Here we rely on something outside of the domain to do that for us and provide the initial, correct, state to the domain.