title: Namespace/solution structure
body: <p>I apologize for asking such a generalized question, but it's something that can prove challenging for me. My team is about to embark on a large project that will hopefully drag together all of the random one-off codebases that have evolved through the years. Given that this project will cover standardizing logical entities across the company ("Customer", "Employee"), small tasks, large tasks that control the small tasks, and utility services, I'm struggling to figure out the best way to structure the namespaces and code structure.</p>
  
  <p>Though I guess I'm not giving you enough specifics to go on, <strong>do you have any resources or advice on how to approach splitting your domains up logically</strong>? In case it helps, most of this functionality will be revealed via web services, and we're a <strong>Microsoft</strong> shop with all the latest gizmos and gadgets.</p>
  
  <ul>
  <li>I'm debating one massive solution with subprojects to make references easier, but will that make it too unwieldy? </li>
  <li>Should I wrap up legacy application functionality, or leave that completely agnostic in the namespace (making an <code>OurCRMProduct.Customer</code> class versus a generic <code>Customer</code> class, for instance)? </li>
  <li>Should each service/project have its own <code>BAL</code> and <code>DAL</code>, or should that be an entirely separate assembly that everything references? </li>
  </ul>
  
  <p>I don't have experience with organizing such far-reaching projects, only one-offs, so I'm looking for any guidance I can get.</p>