命名空间/解决方案结构

我很抱歉问了这样一个笼统的问题，但这对我来说可能是一个挑战。我的团队即将开始一个大型项目，该项目有望将多年来不断发展的所有随机一次性代码库整合在一起。鉴于该项目将涵盖整个公司的标准化逻辑实体（“客户”、“员工”）、小任务、控制小任务的大任务以及公用事业服务，我正在努力找出构建该项目的最佳方法。命名空间和代码结构。

虽然我想我没有给你足够的细节来继续，您对如何逻辑地分割域有任何资源或建议吗？如果有帮助的话，大部分功能将通过网络服务公开，我们是微软购买所有最新的小玩意和小玩意。

• 我正在讨论一种带有子项目的大型解决方案，以使引用更容易，但这会使其变得太笨重吗？
• 我应该包装遗留应用程序功能，还是将其完全保留在命名空间中（制作一个OurCRMProduct.Customer类与泛型Customer例如，类）？
• 每个服务/项目是否应该有自己的BAL and DAL，或者应该是一个完全独立的程序集，所有内容都引用？

我没有组织如此深远的项目的经验，只是一次性的，所以我正在寻找任何可以获得的指导。

剥猫皮的方法有一百万种。然而，最简单的总是最好的。哪种方式对您来说最简单？取决于您的要求。但我遵循一些一般的经验法则。

首先，尽可能减少项目总数。当您每天编译二十次时，额外的一分钟就会累积起来。

如果您的应用程序是为了可扩展性而设计的，请考虑按照设计与实现的方式拆分程序集。将接口和基类放置在公共程序集中。为您公司的这些类的实现创建一个程序集。

对于大型应用程序，请将 UI 逻辑和业务逻辑分开。

简化您的解决方案。如果它看起来太复杂，它可能就是这样。合并，减少。