I was taught that localization belongs strictly in the presentation layer, but I'm curious how this works in real-world applications. Do developers ever use locale or language data directly in core domain or business logic, or should that logic remain completely independent of how information is displayed?
3 Answers
In most cases, keep localization at the edges of the application, such as the UI, document generation, or other presentation code. The domain should describe what the system does without depending on translated strings or locale identifiers. If business rules depend on geography—for example, taxes or regulatory requirements—model that using a country code, region, or another domain-specific value rather than a display locale like “en-US”.
There can be an unusual exception when the domain itself is inherently tied to a particular language. Some fields, legal concepts, or healthcare terminology may be most accurately modeled in the language used by the professionals and users of that domain. That is more about choosing the domain’s vocabulary than about localizing output, though, so it should be treated differently from ordinary presentation localization.
Putting localized strings deep in the service layer usually creates unnecessary coupling. Adding a language or changing a translation can unexpectedly affect core behavior and make testing much harder. For validation and error handling, the business layer can return stable error codes or structured results, and the presentation layer can translate those into user-facing messages.
That distinction makes sense. So the key question is whether language is part of the domain concept itself, rather than merely the way the application displays a concept.