Whenever I develop some software I try to leave the domain model without being influenced by issues relating to other layers of the application such as general technologies and interface issues.
In fact, the domain model contains a code template of the problem being solved, and the goal is to encapsulate the rules and business logic. All of the functionality itself should be within it.
It turns out that recently in a project I received an application of the following type:
In the contact status record you should be able to choose a color for that status. From there, when listing the contacts in a table, the line of a contact should be painted with the corresponding color of its status.
The application is very simple and implementation too. It's just that I was a bit worried because it seems to me that to implement this we ended up mixing the domain with interface issues.
Actually, the most practical way I would imagine doing this would be: given the class StatusContato a Cor property of type string is stored which stores a hexadecimal code of the color. From there the interface manages how this color is saved and used.
Although it works, this is worrying. If we only think about the domain, only in the business, Cor is not a characteristic and not something associated with StatusContato . It is merely something of the user interface.
I can imagine several other requirements of this type, where the user when submitting the requirement mixes domain issues with interface issues.
In this sense, how can this impasse be resolved? How can this kind of requirement be addressed without endangering the domain model with interface issues?