对于提出如此笼统的问题，我深表歉意，但这对我来说可能具有挑战性。我的团队即将开始一个大型项目，希望将多年来发展的所有随机一次性代码库整合在一起。鉴于该项目将涵盖整个公司的标准化逻辑实体（“客户”、“员工”）、小任务、控制小任务的大任务以及公用事业服务，我正在努力找出构建命名空间和代码结构。
虽然我想我没有给你足够的细节来继续下去，但你有任何资源或建议来说明如何在逻辑上分割你的域吗？如果有帮助，大部分功能将通过 Web 服务显示，我们是一家拥有所有最新小玩意和小工具的Microsoft商店。
OurCRMProduct.Customer类而不是一个泛型Customer类）？BALand DAL，还是应该是一个完全独立的程序集，所有内容都引用？我没有组织过如此深远的项目的经验，只有一次性的，所以我正在寻找我能得到的任何指导。
给猫剥皮的方法有一百万种。然而，最简单的总是最好的。哪种方式对您来说最简单？取决于你的要求。但是我遵循一些一般的经验法则。
一是尽可能减少项目总数。当你每天编译 20 次时，额外的一分钟就会增加。
如果您的应用程序是为可扩展性而设计的，请考虑按照设计与实现的方式拆分您的程序集。将接口和基类放在公共程序集中。为贵公司的这些类的实现创建一个程序集。
对于大型应用程序，请将您的 UI 逻辑和业务逻辑分开。
简化您的解决方案。如果它看起来太复杂，它可能是。结合，减少。
我的建议是，在进行了类似的工作后，不要为名称空间而苦恼。
只需从一些重要的松散准则开始开发，因为无论您从什么开始，您的项目都是有机的，随着时间的推移您最终会重新组织名称空间和类。
不要浪费时间过多谈论你的项目。去做就对了。
我最近在工作中遇到了完全相同的情况。许多需要结构化和组织的临时代码。
一开始真的很难，因为有这么多。我认为我能给出的最好建议就是在周五下午的风吹草动中投入时间，几周后我会选择一个应用程序/代码块，检查那里有什么，想想我们能做些什么制作通用的，复制它，把它放到我认为应该放在的新库中。一旦我迁移了应用程序中的所有代码，我就会着手重构应用程序以从通用框架中工作。这有时会导致需要修复的问题，但只要你彻底它不应该太大一个交易。
一点一点，这是唯一的方法。
在结构方面，我试图模仿 MS 命名空间，因为大部分情况下它非常合乎逻辑（例如Company.Data、Company.Web、Company.Web.UI等等。
主要好处之一可能是删除了代码重复的数量。是的，应用程序需要进行一些重构，但代码库要精简得多，并且在许多方面“更智能”。
我注意到的另一件事是，由于我不确定它属于什么，所以我经常在试图弄清楚将东西放在哪里（在命名空间方面）时遇到问题。现在这真的让我很担心，我认为它是一种难闻的气味。由于重组，现在一切都更好地落入太空。并且使用（现在非常少量的）应用程序特定代码，它们被放入Company.Applications.ApplicationName这有助于我更多地考虑业务对象，因为我不想在这个命名空间中有太多东西，所以我想出了更多灵活的设计。
抱歉发了这么长的帖子。这有点漫无边际！
我们在 .NET 中使用以下方式命名程序集 Company.Project.XXXX.YYYY，其中 XXXX 是项目，YYYYY 是子项目，例如：
我们从 Krzysztof Cwalina（作者）、Brad Abrams（作者）的《框架设计指南》一书中获取这一点
对于大型项目，我喜欢采用的方法是为我的业务对象创建一个域命名空间，然后在需要存储和检索业务对象的层中使用数据传输对象 (DTO)。DTO 是一个不包含任何业务逻辑的简单对象。
这是一个解释 DTO 的链接：
包含大量项目的大型解决方案编译起来可能会很慢，但更容易一起管理。
我经常将单元测试程序集与他们正在测试的解决方案放在同一个解决方案中，因为您倾向于一起对它们进行更改。