I’m trying to refine my domain model for the internationalization feature, I wanted to get your input on the best approach to structuring Culture and Localization entities following Domain-Driven Design principles.
I will have to main entities:
- Culture: Represents a specific cultural context with attributes like Id, Description, and Code.
- Localization: Represents a resource key-value pair within a given Culture with attributes like Id, CultureId, ResourceKey and Value.
Two Possible Approaches:
- Culture as an Aggregate Root with Localization as an Entity:
In this approach, Culture is the aggregate root, and Localization is an entity within the Culture aggregate.
This approach could simplify the model if Localizations are tightly coupled with their Culture and do not need independent lifecycle management.
Cons: Potential performance issues and complexity in managing millions of Localizations within a single aggregate.
- Both Culture and Localization as Separate Aggregates:
In this approach, both Culture and Localization are treated as separate aggregates.
This allows Localizations to be updated independently of Culture, supporting a more scalable and performance-oriented design.
Pros: Better scalability, reduced contention in high-concurrency environments, independent lifecycle management.
Cons: More complex to manage relationships between aggregates.
Key Considerations:
- Localizations always have a relation to a Culture.
- Localizations can be updated without needing to update Culture.
- Each Culture can have millions of Localizations.
I’d love to hear your thoughts on which approach you think would be the best and why.
Hélder is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.