I see no justification for different projects at all. You can and usually should have different threads, different assemblies and make some assemblies as plug-ins loading them during run time, depending on configuration.
Splitting the solution into different processes adds good amount of hassles, but what would be the benefits? You would have some benefits if you need a potential for making the application distributed, scalable — adding more client and/or server computer, especially if you need to do this during run time, without stopping of your production. In other cases it would not make any sense. Here is one simple criteria: if you plan to use the whole application on one single computer (I do not count database servers here), there is no sense to make it multi-process. This is one more case when you need more than one process: for interoperability between 32-bit and 64-bit code — they cannot leave on a single process.
So, if you really need to make an application composed from different processes, you need to use, not surprisingly…
IPC (
Inter-Process Communication), see
http://en.wikipedia.org/wiki/Inter-process_communication[
^].
In .NET it can be classical remoting or WCF. Learn about it.
—SA