How to handle requirements that "mix" domain and interface?

Question

Whenever I develop some software I try to leave the domain model without being influenced by issues relating to the other layers of the application like technologies in general and interface issues.

In fact, the domain model contains a code model of the problem being solved, and the goal is to encapsulate the rules and business logic. All functionality itself must be within it.

It turns out that recently in a project I received an application of the following type:

In the contact status registration it should be possible to choose a color for that status. From there, when listing contacts in a table, a contact line should be painted with the corresponding color of its status.

The application is very simple and the implementation too. It just so happens that I was a little worried because it seems to me that to implement this we ended up mixing the domain with interface issues.

In fact, the most practical way I imagine to do this would be: given the class StatusContato add a property Cor string type that stores a hexadecimal color code. From there the interface manages how this color is saved and used.

Although it works, this is worrying. If we think only in the domain, only in the business, Cor is not a feature or something associated with StatusContato. It is merely something of the user interface.

I can imagine several other requirements of this kind, where the user while presenting the requirement mixes domain issues with interface issues.

In this sense, how can this impasse be resolved? How this kind of requirement can be handled without ending up polluting the domain model with interface issues?

Answer 1

I guess it’s not exactly a layering problem. You’re too focused on the domain as an abstract thing and forgetting that the business layer has to model the customer problem, not a generic problem.

For your client, StatusDoContato has a color. It may be that the StatusDoContato of a competing company does not, but its client has.

This does not mean, of course, that there is no room for the separation of responsibilities. It’s the Presentation layer’s role to decide where it will show that color (and as goes on and on if will), but it is the role of the other layers to store and manage the saved color. If a requirement comes in the future that says, for example, that the user can select a color from among several predefined and labeled (red, blue, purple), it will have a part of it in the Presentation (a selection list) and a part in the business layer (convert this selected value to hexadecimal and have saved).

Moral of the story: if you think the way you are thinking, even the status name will be seen as a part of the Presentation layer, since it has a visual representation (characters on the screen) and may be displayed. Your Model and your business layer have to model your customer’s data and domain and your client wants software, after all.