How does one differientiate wrapped layers in the command pattern that are logically named the same?

I have this interface...

public interface ICheckThatDocumentExistsC开发者_开发知识库ommand
{
   bool Execute( string userId, string docId );
}

In the implementation, I only want to validate the two id's and, if valid, to return the result of another interface...

public interface ICheckThatDocumentExistsCommand
{
   bool Execute( UserId userId, DocumentId docId );
}

I want to define the interfaces in the same business domain assembly, but I'm having difficulty deciding how to differentiate the two (or more) layers. Logically, I perceive they are similar if not identical in name, so I can't put them under the same namespace. Do I separate via namespace? A "Validation" namespace and a "Something-else" namespace? Or do I expand the already wordy name into something a bit ridiculous like...

public interface IValidateIdsAndThenCheckThatDocumentExistsCommand

I am seeing this come up more and more as I keep functions small and single-purposed.

Well, its the implementing class that is figuring out what to do with the params....so why not let the implementing class determine and validate the types....

public interface ICheckThatDocumentExistsCommand
{
  bool Execute<t1,t2>(t1 userID, t2 docId);
}

Not an uncommon problem using the command pattern. I can usually keep Command names to four or five words at most, but occasionally something longer is needed.

I see headaches for two interfaces with the same name:

1. Any class that references both assemblies will have to use fully qualified class name.
2. Source control headaches around keeping the files straight in your head (which one am I merging right now?), assuming your file names match your class names.
3. GoTo Type in Resharper will always require an extra step.

I agree that the extra work done by the first interface should be reflected in the name. Your suggestion would work, but you could shorten it to something like

IValidateIdsAndCheckForDocumentCommand

That's not too long. :)

I like Tims answer because it's smart, and I like Thomas's answer because he obviously know the territory.

If it were me, I'd most likely use different namespaces.