title: Organizing code in separate Projects vs separate Namespaces
body: <p>I work in a .net c# application which contains 2 solutions for client and server. In server side there are 80+ projects that have been used to separate following Architectural layers, </p>
  
  <ul>
  <li>Infrastructure Layer </li>
  <li>Integration Layer (External Systems)</li>
  <li>Domain Layer  </li>
  <li>Repository Layer </li>
  <li>Manager Layer</li>
  <li>Service Layer</li>
  </ul>
  
  <p>In addition, almost every layer has test project.Now, the build time of the solution takes 2 to 3 minutes, and many developers (including me :)) feel we need to tackle this problem.</p>
  
  <p>Therefore,proposed solution was to reduce the number of projects by merging the projects.In my view, it is probably a good solution to minimize the build time and we could achieve what we want.</p>
  
  <p>Proposed solution is that we merge our projects into 3 areas, such as one library for production code, one library for test code, and one for deployment projects (WCF host ,etc) and logically divided layers in same project by separating the namespaces.</p>
  
  <p>However, my concerns are</p>
  
  <ol>
  <li>Could these separation good for the maintainability ? providing that more that hundread of classes for each namespace appox.</li>
  <li>If we have common functionality such as helpers, where are we put those ?</li>
  </ol>
  
  <p>Is there any other way to layering the solution ?</p>