Everything that implements Truck is a Type of Truck.
The name of the interface should describe the abstract concept the interface represents. Any implementation class should have some sort of specific traits that can be used to give it a more specific name.
this is one sensible interface naming option, if the interface encapsulates a cohesive set of behaviors
and yes, compared to blindly following the meaningless I+ convention, it requires some thought, but thinking of an appropriate name also forces you to (re)consider the interface's primary responsibility and how it fits into the overall design
imho, a class diagram for a domain model should be almost fluently readable english
Sometimes an Adjective doesn't make sense, but I'd still generally be using interfaces to model behavior, actions, capabilities, properties, etc,... not types.
Also, If you were really only going to make one User and call it User then what's the point of also having an IUser interface?
another anti-pattern... blindly create an interface for every class, even if there's only one implementation!! arrgghhhh!
consider introducing an interface when there are 2-3 well-distinguished, concrete implementations required
if you are going to have a few different types of users that need to implement a common interface, what does appending an "I" to the interface save you in choosing names of the implementations?
prefer not to use a prefix on interfaces:
hurts readability.
interfaces names should be as short and pleasant as possible
Implementing classes should be uglier to discourage their use.