In the same way that we normalise and denormalise data in a relational database, we have to generalise and specify domain model design in the application.
Developers have a tendency to want to generalise things to an extreme but this often results in losing meaning. Whenever you see something called Object or Entity then it’s gone too far.
A co-worker and I had a discussion about creating a class called LookupItem to represent all reference data. There is no domain meaning in the term LookupItem. It is not a word that our business users would use so it isn’t a word we should use. If you find that commonality then let all your domain model classes inherit from a base class but still have their own class with a meaningful domain object name.
You will end up with lots of small classes but you retained a lot of meaning. Someone who walks in after you and goes to maintain the system will not have to read through the code and see what your named variables to see what a class is used for. It is in the class name.
There is also extensibility inbuilt in to this kind of structure. Often extensibility is required when there is an exception to a rule. Always build your generalisation so they can cope with exceptions to the rules.
Generalise but don’t lose meaning.
