n 层和清洁架构之间的主要和明显区别
Main and visibly apparent difference between n-tier and clean architecture
免责声明。我不是在寻找这两者的讨论或意见。我也不打算评估或描述它们。我在一个项目中，我应该设置一条从传统重构到域驱动重构的路径，我希望保持尽可能小的更改仍然可以完成任务。
根据 clean architecture, the onion shaped diagram is supposed to differ from the n-tier architecture 的 MS 文档，它是层状的。
阅读时一切都有意义，但是随后，呈现了干净架构的不同视图，它看起来与 n 层架构非常相似。当然，我确实理解这些差异，但试图理解 where 和 how 的核心点并不会因为这种相似性而变得更容易.
我不确定的一个更好的例子是 this blog。它与 .NET 无关，但架构在技术上应该是不可知的。据我了解，该过程的实际路径是基于层的并且精确地等同于n层版本（仅在绘制方式上有所不同，这应该无关紧要）。
这两种架构类型之间的主要区别仅仅是我们如何使用它们，还是在代码方面或项目结构中存在实际差异（当然，命名除外）？
As far I understand, the actual path of the process is layer based and precisely equivalent to n-tier version (only differing in how it's drawn, which should be irrelevant).
是的，没错。
Is the main difference between those two architecture types simply how we're using them or is there an actual difference code-wise or in the project structure (except for the naming, of course)?
不同之处在于哪个代码了解、引用、取决于其他代码。
在N-Tier中，业务逻辑需要知道基础设施层的API。所有依赖项都指向下方。
在干净的 architecture/onion 架构等中，基础设施层了解领域层的 API。所有的依赖指向向内.
Clean architecture puts the business logic and application model at the center of the application. Instead of having business logic depend on data access or other infrastructure concerns, this dependency is inverted: infrastructure and implementation details depend on the Application Core.
这种风格通常伴随着 Composition Root 的使用，它负责将最终完成工作的组件连接在一起。
Are you saying that there's no business logic layer in onion version? I.e. that it's baked in into the application core?
通常，业务逻辑被理解为位于洋葱的中间。例如，Robert Martin offers
You may find that you need more than just these four. There’s no rule that says you must always have just these four. However, The Dependency Rule always applies. Source code dependencies always point inwards.
免责声明。我不是在寻找这两者的讨论或意见。我也不打算评估或描述它们。我在一个项目中，我应该设置一条从传统重构到域驱动重构的路径，我希望保持尽可能小的更改仍然可以完成任务。
根据 clean architecture, the onion shaped diagram is supposed to differ from the n-tier architecture 的 MS 文档，它是层状的。
阅读时一切都有意义，但是随后，呈现了干净架构的不同视图，它看起来与 n 层架构非常相似。当然，我确实理解这些差异，但试图理解 where 和 how 的核心点并不会因为这种相似性而变得更容易.
我不确定的一个更好的例子是 this blog。它与 .NET 无关，但架构在技术上应该是不可知的。据我了解，该过程的实际路径是基于层的并且精确地等同于n层版本（仅在绘制方式上有所不同，这应该无关紧要）。
这两种架构类型之间的主要区别仅仅是我们如何使用它们，还是在代码方面或项目结构中存在实际差异（当然，命名除外）？
As far I understand, the actual path of the process is layer based and precisely equivalent to n-tier version (only differing in how it's drawn, which should be irrelevant).
是的，没错。
Is the main difference between those two architecture types simply how we're using them or is there an actual difference code-wise or in the project structure (except for the naming, of course)?
不同之处在于哪个代码了解、引用、取决于其他代码。
在N-Tier中，业务逻辑需要知道基础设施层的API。所有依赖项都指向下方。
在干净的 architecture/onion 架构等中，基础设施层了解领域层的 API。所有的依赖指向向内.
Clean architecture puts the business logic and application model at the center of the application. Instead of having business logic depend on data access or other infrastructure concerns, this dependency is inverted: infrastructure and implementation details depend on the Application Core.
这种风格通常伴随着 Composition Root 的使用，它负责将最终完成工作的组件连接在一起。
Are you saying that there's no business logic layer in onion version? I.e. that it's baked in into the application core?
通常，业务逻辑被理解为位于洋葱的中间。例如，Robert Martin offers
You may find that you need more than just these four. There’s no rule that says you must always have just these four. However, The Dependency Rule always applies. Source code dependencies always point inwards.