Return look up values SOLID and clean architecture

Question

Our application has multiple drop down lists with data that is dynamically loaded from the database.

• Drop down list of colours
• Drop down list of Sizes
• Drop down list of makes
• Drop down list of models

We called 4 different procedures:

GetColours 
GetSizes
GetMakes
GetModels

Historically, we map the results from those procedures to a generic model class:

public class Lookup
{
    public int Key { get; set; }
    public string Key_Value { get; set; }
}

This generic model is passed through to the front end, and we set option and option value to the key and key/value properties.

We are re-writing the application using clean architecture and SOLID principles.

The question is, is it still correct to map to a generic model, or it is preferred to create a separate model for each look up (SOLID), ie,

public class colourLookup
{
    public int colourId { get; set; }
    public string colourName { get; set; }
}

public class makeLookup
{
    public int makeId { get; set; }
    public string makeName { get; set; }
}

etc

Answer 1

Either way you look at it, Lookup is a data model, not a business class. As long as it does one thing and one thing only, is unlikely to change in the future as requirements change, is easily testable (can be mocked), and any applicable part of the Interface Segregation Principle and Dependency Inversion Principle are observed, it's fine like it is.

If you're feeling particularly nervous, just have your colourLookup and makeLookup derive from Lookup, with no specific behavior themselves.