洋葱架构——选择正确的“模块”方法答案

【问题标题】：Onion Architecture - Choosing the right "module" approach洋葱架构——选择正确的“模块”方法
【发布时间】：2018-08-24 07:35:16
【问题描述】：

我已经研究了几个星期的洋葱架构，我偶然发现了一个技术难题。

当我说“模块”时，请注意我指的是项目的概念。更清楚地说，它兼容： module = .NET 程序集/Java gradle 模块

到目前为止，我在大多数 Onion 架构项目中都看到了 2 种模块模式，它们是：

1 - 每一层都有自己的模块，所以它会有：

2 - 所有相关模块都封装在一个模块中：

第二种方法对我来说更直接，但我不确定它是否会在未来导致依赖性问题。有什么建议吗？

【问题讨论】：

我认为没有明确的“正确”方式。我倾向于使用与您的 option 2 类似的东西，直到我需要拆分功能。在这种情况下，这些位开始向选项 1 移动。我发现从 选项 1 开始会导致移动部件太多。
我同意从选项 1 开始不是一个好主意，因为您提到的原因。我担心我最终会得到一个臃肿的核心和一个臃肿的基础设施，但正如你所说，如果需要，我可以拆分新功能/基础设施问题。谢谢埃本！
@ViníciusM.Freitas 解决方案 1 中可能存在循环引用。另外，您指的是哪种服务？
@guillaume31 - 我不认为可能存在循环引用，因为所有依赖项都指向中心，因此，每一层只能依赖内层，而不能依赖外层。我指的服务是域服务。您能否详细说明第一种方法如何导致循环引用？
我以为它们是应用程序服务——顺便问一下，你有吗？即使使用单独的域服务模块，您也可以拥有实体（取决于）存储库接口（取决于）实体。

【解决方案1】：

你拥有的模块越多，对象之间的依赖就越不灵活，因为你受到洋葱架构严格依赖方向的约束。

设计#1 对我来说似乎过于细化。特别是，将接口与实现分开会阻止您从实现模块中引用接口模块，这可能会受到限制。有时A 中的对象需要松散耦合到B 中的对象，该对象的接口在A 中声明（想到 DDD 存储库）。

【讨论】：