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.
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.
Share Improve this question edited Mar 31 at 11:22 ASh 35.7k9 gold badges65 silver badges87 bronze badges asked Mar 31 at 8:40 Mike93041Mike93041 3891 silver badge9 bronze badges 5- If the only impact of considering an auto-generated database id as a domain invariant is that the system needs to guarantee its uniqueness and the database already does that, then what is the issue? – Good Night Nerd Pride Commented Mar 31 at 11:07
- The issue is about when to enforce uniqueness as a domain invariant versus treating it as a technical constraint. For example, if an auto-generated ID is a domain invariant, then its uniqueness should be verified in a domain service (with the repository injected). Otherwise, it can be checked at the application service layer using the repository. – Mike93041 Commented Mar 31 at 17:10
- But why would it need to be checked if the DB already does that? – Good Night Nerd Pride Commented Mar 31 at 19:49
- 1 You should google for "DDD trilemma" and you'll find interesting articles about this dilemma – EasterBunnyBugSmasher Commented Apr 3 at 10:43
- @EasterBunnyBugSmasher Indeed this is it. Thank you very much. – Mike93041 Commented Apr 3 at 16:19
1 Answer
Reset to default 1My 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.