Today, I’ll share a short but interesting question (and my answer to it) about error mapping.

Here’s the question itself:

It’s quite a typical use case. The most common example is when the application validates the username and password when logging in the user.

There could be multiple validation errors in this scenario, including:

For security reasons, you can’t display the exact validation error to the user. All you can show is the genetic "username or password is invalid".

Where should that mapping from the specific to the generic error go? In the domain or application layer?

It should go to the domain layer.

The cleaning/error mapping is a domain concern. It originates from the business requirement, which means it should be part of the domain.

Introduce a separate domain class like ErrorMapper, ErrorCleaner, or similar.

This would not only put this logic where it belongs, it would also simplify the controller and improve testability: it’s much easier to unit test a method with a single Error argument, than a whole controller working with multiple out-of-process dependencies.

That’s by the way the essence of the Humble Object pattern. The idea is to extract an important piece of logic (the error mapper) out of controllers in order to ease up unit testing of that logic.