Let's assume that I have an attribute called Ticket_Case that has a predefined value (for the sake of arguments, say 1 to 20) that model different real-life use cases. They are an attribute to an ticket itself.
In a different context of the system, I need to generate different messages based on the ticket case. These specific messages are used in this one place, and nowhere else.
The pragmatic solution would be to create a huge switch / case function that maps a case to a message. The less pragmatic, but also less error-prone solution would be to directly attach the message into the Ticket_Case object in some way. Okay, sure that works. It's muddling two different contexts a bit, but that's ok.
But now assume we have a growing number of contexts. Each of them don't really have a lot of similarity, so code reuse is not an option. We could group them all together in the specific Ticket_Case object, but that puts a lot of responsibility into that object. But the other alternative would be the huge switch / case method in every context boundary to translate the Ticket_Case to the corresponding object. This alone screams for many easy-to-miss issues if a new Ticket-Case were ever introduced.
So my question is: What is an acceptable way to deal with these "huge enums" that have correct, yet different uses in different places of the system, without having them either grow out of control internally or creating a lot of brittle mapping code?