Strategy tips on partitioning assemblies and namespaces

Question

A very common complexity for technical architects is to divide the application in assemblies and namespaces.

• Assemblies can be partitioned according: deployment, performance and security boundaries.
• Namespaces can be partitioned according logical application boundaries.

Also: namespaces can span multiple assemblies.

I had a bad experience in a project once where we partitioned assemblies according logical units of the application. This decision ended up with solution files with 30 or 40 projects! The master solution file loadtime was approx. 5 minutes!!! This ended up in a great waste of time, pff...

The opposite scenario was to hold all code in 1 assembly and partition when it is really needed.

Do you have additional tips or best-practices regarding this issue?

Answer 1

I split code into separate assemblies only when I need to reuse it for two different applications (pretty much). So I start with everything in one project, and when the need to reuse code becomes obvious I create a new assembly and move the code (sometimes its obvious from the very beginning, e.g. when you need to have a web app and win forms doing same thing).

Re. Namespaces, I prefer to have it quite well partitioned within an assembly, so it is clear where each class belong and what it should be used for.