Here is a simple reality check for you: do models (entities) in your project tend to have names like
ContentItem? If so, your project may not be meaningful to your users. You’re probably going to (or already do) have problems in communicating with them.
You see, the end users and domain experts don’t think in this terms. They don’t order “items” to build some “thing”. They order laser cannons and remote controllers to build a giant laser-beam-shooting, remote-controlled robot.
If you call some entity an
Object it means you don’t really know what it is and what it does. I bet the domain experts don’t call it an “object”, they call it “a part used to build a giant robot”. Can you see how much more information is given by a good name? Your “object” is a
Part, so it has some technical characteristics, it belongs to some robot(s), it is probably stored in some warehouse, it may have a price, versions, dependencies, requirements, subclasses etc. This list could go on and on.
On the other hand what does the name
Object tell you? From my experience, it tells you that the developers don’t understand the users, the users don’t understand (and hate) the application, the specs are missing or outdated and no-one is able to identify a single use-case for the system. In short, not much of a success.
So, what’s your favorite meaningless name?