It’s not uncommon in an application to have different representations of the same concept in different contexts. For instance you may have a concept encoded as a domain object and also as a type in a message contract. In this case you will generally want to use the same name in each context. However this has the disadvantage that the class name is now somewhat ambiguous.

In such cases there will likely be at least one place in the code where you will need to refer to both contexts. This necessitates a mechanism for distinguishing between the types from each context. The result that you will need to qualify type names. You may chose to include the namespace of one context and qualify the types of the other context. In practice I find this problematic because it requires the application of a convention that is not obvious and of which tooling is unaware. This may result in inconsistency in qualification between code files which may be confusing.

To alleviate this concern you can choose to qualify all types from both contexts. I find this preferable as it removes a potential source of ambiguity. Unfortunately some tools will attempt to be helpful and remove the qualifications. The removal of qualifications is unlikely to be consistent between code files which means this assistance must be undone. This is a small but noticeable cost when editing these files.

I tend to consider having to use qualification of types within a single solution to be a failure of type naming. In some cases this will be because a name is being incorrectly carried between contexts. When dealing with our example of a domain and a message context it will generally be the case that there shouldn’t be a one-to-one correspondence between domain and message types. The existence of a Product domain type does not necessarily imply that there should be a Product message type. In this case message types that better align to the purpose of a message context may be more suitable. We may chose to have messages such as UpdateProduct or ProductCreated which are more relevant to the business purposes to which messages may be put (in this case a command and a notification message respectively).

Using names more suitable to their context will significantly reduce the duplication in names but there will always be exceptions. For instance in most systems an Address is a value object that is relatively similar regardless of context. As addresses are rarely entities in their own right it is likely that they will be a component of other types in a context rather than being used directly. As such there is not really the opportunity to assign business specific names in each context.

My solution to this is to have an agreed suffix for type names within each context. This allows any type from a context to have a name that is clear and unambiguous without qualification. This suffix is generally redundant when the full type name including namespace is considered. In this usage I feel that the redundancy is acceptable due to the improvements achieved in actually using the types. This convention is also more obvious that picking which context is to be qualified or qualifying all contexts, and is significantly more likely to be followed consistently in a team environment.