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:

  1. 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.

  1. 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.

  • 1
    How do your domain stakeholders view the concept of internationalization, especially if you don't make it a given that the implementation will be done in software (i.e., it might be old-fashioned paper and pen)? Do they consider it as "just translate the forms and you are done" or does it have actual impact on the business? Commented Jun 26 at 14:57
  • 1
    Also consider the way these are used, referred to, externally. With the former, the path to a localization will have to have the culture id and the localization id, but the localization id doesn't have to be unique across cultures, whereas with the latter, the localization id's must be unique regardless of culture, while the path to a localization won't need a culture id.
    – Erik Eidt
    Commented Jun 26 at 15:01
  • @BartvanIngenSchenau, The users will have the hability to manage the translations.
    – Hélder
    Commented Jun 26 at 15:52
  • Who are “the users” and what abilities do they have?
    – gnasher729
    Commented Jun 26 at 15:53
  • 2
    Translation and localization is probably a context that is completely separated from your main context. I would treat it as such. It’s probably also not a core domain for your business, but a generic subdomain, meaning you should really question if this is worth putting a lot of development effort into, or if you should look into off-the-shelf solutions.
    – Rik D
    Commented Jun 26 at 17:20

2 Answers 2


The key here is proper separation of concerns, and more precisely separating domain concerns and implementation constraints.

From your own domain description, I understand that the localisation makes no sense without culture and will probably always be accessed via a culture:

Localization: Represents a resource key-value pair within a given Culture with attributes like Id, CultureId, ResourceKey and Value.

This makes localisation a very good candidate for being an entity in a culture aggregate. The fact that you already identified that it would considerably simplify things, is a confirmation that it's probably the right approach.

The only cons that you have identified is not related to the domain: it's an implementation constraints, i.e. being able to deal with millions of localisation in a culture with good performance. Implementation constraints should not harm your domain understanding.

What's the real problem here? Could it be that you assume that all the entities of an aggregate have to be loaded at once? This assumption is not founded even if it is a common and popular practice. There are plenty of techniques to deal with such constraints, a few being for example the lazy load (for loading only what is needed) and the unit of work (for keeping consistence when objects in the aggregate entities are to be changed).

P.S: The culture/language issue is a little bit different, in the sense that languages exist independently of cultures, though can be influenced by culture. A more complex model would then be needed, allowing for independent culture and language, but dependent cultural language variants.


Localisation and internationalisation are pretty much solved problems with multiple off the shelf solutions and it's unclear what your requirements are.

If you want to write your own dynamic solution you only need a single "culture code" to identify the requested localisation options with a key lookup for the translated string


"title", "StackExchange"

"title", "Le Exchange al la Stack"

You never really need to get all the fr-FR strings at once, just the ones you need for whatever UI you are showing. And you don't really have "millions" of them.

I suppose you could optimise with a pageid per row, but it would make reuse annoying.

  • Just saying: “StackExchange” is most likely not something you want to translate.
    – gnasher729
    Commented Jun 26 at 17:54
  • dont blame me for the french!
    – Ewan
    Commented Jun 28 at 9:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.