我一直在研究耦合指标，也在研究DSM。

我一直使用的一种工具着眼于"模块"之间的耦合，其中模块是分发单位(在本例中是.net程序集)。

我觉得我应该更关注包(或者名称空间)之间的耦合而不是分发单元。

我应该更关注包/名称空间之间的耦合(确保抽象仅依赖于抽象，具体类型依赖于抽象，并且它们在依赖关系中没有循环，以便于重构和扩展很容易)还是我应该关注是否部署新版本而无需更新不变的发行单位？

其他人会衡量什么？

就其价值而言，我的直觉是，如果我专注于包/名称空间耦合，那么分配耦合单元将免费出现，或者至少会变得更容易。

解决方案

分配单元之间的耦合和依赖性循环更为"致命"，因为这可能使部署程序变得非常困难，有时甚至使编译程序变得非常困难。

我们大体上是对的，一个好的顶级设计可以将代码分成逻辑包，并且只有清晰和预定义的依赖关系才能带给我们大部分的帮助，唯一缺少的是将包正确地分成发行单元。

首先，很容易过度研究依赖关系和耦合。确保我们没有使它复杂化。

有了这个免责声明，这就是我的建议。

依赖/耦合管理实际上有3种不同的视图：
1)物理结构(即程序集依赖项)
2)逻辑结构(即名称空间依赖项)
3)实现结构(即类依赖关系)

对于大型应用程序，我们至少需要检查所有三个，但通常可以确定优先级。

对于客户端部署的应用，数字1可能非常重要(即对于插件之类的东西)。对于部署在企业内部(即asp.net)的应用程序来说，项目＃1通常并不那么重要(不包括跨多个应用程序重用的框架)。通常，我们可以很轻松地部署整个应用程序，而不会占用＃1的复杂结构的开销。

项目＃2往往更多是可维护性问题。了解图层边界及其与名称空间的关系(即，我们是否为每个名称空间做1层，或者在逻辑级别包装不同)有时，工具可以通过查看逻辑依赖关系结构来增强图层边界。

第3项实际上是关于做好课堂设计的。每个优秀的开发人员都应该付出大量的努力，以确保他只在自己的类中承担适当的依赖关系。说起来容易做起来难，并且通常是随着时间的推移必须掌握的一项技能。

为了让我们更接近问题的核心，第1项实际上是关于VS解决方案中项目的布局方式。因此，这不是要衡量的项目。它更多地是我们在开始时设置并运行的。第2项是我们可以在构建过程中使用工具检查开发者是否违反任何规则的工具。实际上，这更多是检查而不是措施。第3项确实是我们想要很好地进行测量的一项。在代码库中查找具有大量耦合的类将是很痛苦的事情，请确保这些人的质量。同样，在此级别进行度量可以使我们对代码库的质量(总体)进行评估。另外，如果有人将一些真正不修边幅的代码签入代码库中，它还会给我们带来危险。

因此，如果要确定优先级，请快速查看＃1和＃2. 知道他们应该是什么样子。但是对于大多数应用而言，第3项应该花费最多的时间。

当然，此答案不包括大型框架(如.NET BCL)。那些婴儿需要特别注意＃1. :-)

否则，我们将遇到以下问题：
" .NET Framework的当前版本包括各种基于GUI的库，这些库在Server Core中无法正常工作"
http://www.winsupersite.com/showcase/win2008_ntk.asp

在Windows Server 2008的无GUI安装中无法运行.NET的地方，因为该框架依赖于GUI库...

最后一件事。确保我们熟悉良好的依存关系/耦合管理的原理。我们可以在此处找到一个不错的列表：

http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod