architecture - 分层架构中同一层的模块

Question

理论上，在分层架构中，您可以在同一层上拥有多个模块。这个模块可以相互交叉引用吗？在技​​术上是可能的，例如。使用.NET？

Answer 1

当然可以这样做，只是注意不要在模块之间引入任何循环依赖。一般来说，给定层的模块应该只依赖于同一层或它下面的层的其他模块。模块不应该知道它们上面的层。

如果您想让这一点更加严格，那么您还可以限制对来自当前层下的同一层或其他层的其他模块的依赖。

将公开的接口保持在最低限度，例如只公开一组核心的公共接口、值对象和异常总是一个好主意。您可以使用语言的访问控制功能（即私有/包/公共）来限制模块内部的可见性，以免溢出到其他层。

Answer 2

从技术上讲，您可以在 .NET 中按照您想要的任何方向进行交叉引用（DAL 引用 UI 组件没有技术限制，即使这可能不是一个好主意）。我认为在同一层中引用模块没有问题。

但是我们需要稍微看一下“层”这个词，因为层有不同的形状和大小。通常，当我们使用“层”这个词时，我们会想到数据访问层或表示层，我们通常允许层向下看，但不能向上看。

在每一层内，不同的模块通常也让它们自己按逻辑排列成层。同样的规则在这里适用；一个模块可以向下看，但不能向上看。考虑到这一点，在同一（外）层中引用模块感觉相当安全。

只是不要让两个模块直接或间接地相互引用。如果您发现 A 和 B 都需要彼此的功能（表明 A 和 B 处于同一级别），您可能需要重构代码，可能需要引入一个新模块 C，在逻辑上放置在 A 和 B 下方其中可以使用。

还要记住使模块尽可能分离；他们对彼此的了解越少越好。

Answer 3

正如 Pavel 所说，小心你的循环依赖。如果你绝对不能没有循环依赖（你称之为交叉引用），那么这些类不仅必须来自同一个“层”，而且还必须来自同一个程序集。

话虽这么说，不应该有交叉引用的理由 - 不仅应该（如pavel所说）模块只依赖于它们下面的层，而且在所有情况下都应该存在单向依赖关系。

这条规则有一些逻辑上的例外，例如在领域模型中——例如，客户将有许多订单。在这种情况下（尤其是 ORM 等），拥有一份关于客户的订单列表以及每个订单对客户的引用可能会很有用。就服务等功能单元而言，应该只有一种方式依赖。

解决此问题的一种方法是通过 Windsor、autofac、spring.net 等使用控制反转。您可以在程序集中定义一个接口，以及另一个使用该接口的具体实现的对象。另一个库可能包含实际的实现（这意味着程序集必须引用第一个程序集）。在这种情况下，IoC 容器会抓取实现。