我刚刚参加了一个设计会议，并向我提出了一个问题，即我在哪里得到了关于如何构建我们正在构建的项目的一些.dll的想法。说实话，我不知道这个“想法”来自哪里，对我来说似乎是天生的知识。但是，如果我能通过一些记录分析来支持这些意见，那将是有用的。
是否有人知道明确讨论构造程序集/模块/源的不同机制的任何资源？
更新：
这个想法没什么特别的。我们正在讨论某些硬件的抽象层，因此使用这些服务的“应用程序”可能是（某种程度上）平台无关紧要的。以前我们有一个接口.dll来声明应用程序所需的接口，以及一个实现.dll，它实现了我们迄今为止所拥有的一个平台。现在我们有两个平台，但它们非常相似。为了防止接口.dll被污染或者实现引用彼此的一些可怕场景，我只是建议我们创建另一个位于接口和specificplatform.dlls之间的.dll，其中常见的抽象实现可以存在。
答案 0 :(得分：2)
如果你有机会，请看看Robert C. Martin的书：
Agile Principles, Patterns, and Practices in C#（这是专门针对.Net的新版本）
有一章致力于组件设计（可能）回答了你的问题。
总之，在阅读完本书之后，我总是建议按以下标准分离组件：
程序集是单位或重用：如果有必须一起使用的类，它们会进入同一个程序集。
程序集是变更的单位：如果有些类由于同样的原因不必更改，它们可能不应该在同一个程序集中。
程序集是部署的单位：如果有必须在同一个地方进行物理部署的类，它们可能应该放在同一个程序集中。
当然这些只是启发式而不是食谱。您最终需要根据应用程序的体系结构目标（特别是部署和进化/修改的体系结构目标）来确定所需的三种设计启发式中的每一种。