Should Localization Be Part of Domain or Business Logic?

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.

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.

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