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.
Though I guess I'm not giving you enough specifics to go on, do you have any resources or advice on how to approach splitting your domains up logically? In case it helps, most of this functionality will be revealed via web services, and we're a Microsoft shop with all the latest gizmos and gadgets.
OurCRMProduct.Customer class versus a generic Customer class, for instance)? BAL and DAL, or should that be an entirely separate assembly that everything references? I don't have experience with organizing such far-reaching projects, only one-offs, so I'm looking for any guidance I can get.
There's a million ways to skin a cat. However, the simplest one is always the best. Which way is the simplest for you? Depends on your requirements. But there are some general rules of thumb I follow.
First, reduce the overall number of projects as much as possible. When you compile twenty times a day, that extra minute adds up.
If your app is designed for extensibility, consider splitting your assemblies along the lines of design vs. implementation. Place your interfaces and base classes in a public assembly. Create an assembly for your company's implementations of these classes.
For large applications, keep your UI logic and business logic separate.
SIMPLIFY your solution. If it looks too complex, it probably is. Combine, reduce.