那里有很多关于设计模式（例如访问者）、SOLID（单一职责等）、KISS（保持简单、愚蠢）、分层设计等的文档。
我不完全理解的一件事是如何决定在扩展应用程序时何时需要新项目/DLL。有没有使用的标准？
例如，System.Windows.Forms (http://msdn.microsoft.com/en-us/library/system.windows.forms.containercontrol.aspx) 是 System.Windows.Forms.dll 的一部分，但它派生自 System .MarshalByRefObject，它是 mscorlib.dll 的一部分。
您正在混淆程序集 (DLL) 和命名空间。
程序集是包含类实现等的二进制文件。
命名空间只是一种将类、枚举等组织成逻辑组的方法，以防止每个级别都可以访问每个类，并防止命名冲突（例如System.Windows.Forms.Timer和System.Threading.Timer）。
System.Windows.Forms不派生自System，System也不只存在于 mscorlib.dll 中。任何人都可以在命名空间中放置任何东西System——甚至你也可以这样做。它只是System.
将代码子集拆分为单独的程序集有几个原因。一个重要的问题是可重用性。如果您有一些通用控件或实用程序，您可以在自己的 DLL 中维护它并在项目之间使用它，而无需复制和粘贴代码。
不要将层与层混淆。分层代码几乎总是必须的。然而，将您的代码拆分成单独的物理层通常是您在实际需要之前不想做的事情（遵循 KISS 原则）。
如果您正确地分层代码，那么当您需要将其分解为单独的层时，这样做应该是一个非常轻松的过程。但是，如果您从未正确地对代码进行分层，您会发现拆分这些层将非常困难。
作为一个简单的例子，假设您创建了一个登录表单，假设您将收集系统信息、访问数据库、验证用户凭据和构建权限的所有逻辑都直接放入 WinForm 类。我刚才描述的代码只有 1 层，也只有 1 层。如果您随后发现自己需要使用 ASP.NET 创建基于 Web 的登录页面，您会发现重用现有代码非常困难。使用基于 Web 的登录，您至少希望将 UI 逻辑与业务/数据访问逻辑分开，但因为它都直接在 WinForm 类中，如果不重构代码，它就无法使用。
现在，假设您没有将所有代码放入表单中，而是花时间将其正确分层。假设您分解了所有访问数据库的代码，将其全部放入数据访问类中。然后你把所有的业务逻辑代码都放到业务类中。此时，WinForm 类中的实际代码应该仅限于只做与 UI 相关的逻辑，例如处理控件事件、设置标签等。在第二个示例中。您仍然只有 1 层，但您拥有三个不同且独立的层（即 UI、业务、数据访问）。
如果您已经对代码进行了这样的分层，那么当您需要在基于 Web 的项目中重用它时，您可以轻松地将业务和数据访问层移动到类库 (dll) 中，然后在服务器端层的 ASP.NET 项目。
将代码分解为单独的类库通常仅在两种情况下才需要：
即使你把所有的代码都放在一个项目中，只要分层好，当这种情况出现时，很容易将项目拆分成多个类库。所以最大的设计问题不是你有多少 DLL。相反，最大的设计问题是你有多少层。一旦您将代码分层，就可以根据需要在不同项目之间轻松移动它。
实际上，即使您不需要在项目之间重用代码也不需要支持 n 层，您仍然可以合理地选择将层划分为单独的类库。纯粹出于组织目的或为了一致性而这样做可能是有意义的。例如，如果另一个开发人员在您身后看到名为“MyCompany.Feature.Business”的类库中的类，他们可以安全地假定这些类都是业务逻辑层的一部分。这样，将您的代码分解为单独的类库可以是自记录的。
将代码放入 dll 中还有其他原因。例如，它使支持插件架构变得容易，或者使一次更新应用程序的一部分变得更容易。