洋葱-六边形架构依赖混淆
Onion-hexagonal architecture dependency confusion
我无法理解六边形（端口适配器）架构中依赖的含义。
Here 他们的照片不错。我没有看到的是与n层结构有什么区别（实现）。
在onion/hex架构中，内部层应该独立于外部层，但它是如何实现的（请注意我的 java/spring 背景）
在 N 层中，您可以自动连接第 N+1 层组件。我看到了依赖的方向，但是你怎么能恢复它：-/
如果我要调用 outer layer，我将使用接口。
所以接口在内层，实现在外层。现在我独立于外。就是这个？就是关于API放在哪里？
无论如何 hex/onion 应该独立于依赖解析，所以这是否意味着我不应该使用 @Autowire、@Inject 等？？
非常感谢您提前澄清。
哇，这么多问题。我会尝试一个一个地完成它们
In onion/hex architecture the outer layers should be independent from inner ones, but how is it implemented(please note my java/spring background)
对于架构模式，您会看到很多不同的解释，但这个让我觉得很奇怪。洋葱模式的内部部分是您的领域逻辑，而外部部分是其他领域或技术（数据库、网络服务……）的适配器。您不希望您的域依赖于这些技术细节，因此外部可能依赖于内部，但反之则不然。
In N-layered you auto-wire the N+1th layer components. I see the direction of the dependency, but how can you revert it:-/
这叫做控制反转。您的域（内部部分）经常需要调用适配器（例如您的数据库访问逻辑），因此在 运行 时间必须存在依赖关系。但是在编译时你不想要这样的依赖，以便能够替换所使用的特定技术。您可以通过使用接口和依赖注入来做到这一点。示例：您的域可能需要访问所有品牌的列表。为此，您创建一个如下所示的界面：
public interface BrandRepository{
public Set[Brand] all()
}
此界面是您域的一部分。您当然有该接口的实现，可能基于 Jdbc（或内存列表或 Web 服务）。此实现位于洋葱的外层。由于接口的实现依赖于内部，正如所要求的那样。
If I'm about to call outer layer, I will use interface. So the interface is in inner and implementation in outer layer. Now I'm independent on outer. This is it?
是
It is just about where the API is placed?
很难回答：你的API是什么？您的域模型是适配器的 API。适配器是您系统或其他系统的其他部分的API。
Anyway the hex/onion should be independent from dependency resolution, so does it mean I should not use @Autowire, @Inject etc??
现在可以争论一个世纪了。严格来说，这些注释依赖于您的 DI 框架。但是，由于这些得到了标准化，它们变得更加依赖于您的语言（如果不进入无限递归并收集大量语言设计经验，您将无法避免）。对注释的依赖，根据定义不能包含任何实现，这不是什么大问题，我个人对在我的代码中使用它们感到满意。
What I don't see is what is the difference(implementation) from n-layer structure.
洋葱结构是 n 层架构这一相当笼统的术语的特定变体。
我无法理解六边形（端口适配器）架构中依赖的含义。
Here 他们的照片不错。我没有看到的是与n层结构有什么区别（实现）。
在onion/hex架构中，内部层应该独立于外部层，但它是如何实现的（请注意我的 java/spring 背景）
在 N 层中，您可以自动连接第 N+1 层组件。我看到了依赖的方向，但是你怎么能恢复它：-/
如果我要调用 outer layer，我将使用接口。 所以接口在内层，实现在外层。现在我独立于外。就是这个？就是关于API放在哪里？
无论如何 hex/onion 应该独立于依赖解析，所以这是否意味着我不应该使用 @Autowire、@Inject 等？？
非常感谢您提前澄清。
哇，这么多问题。我会尝试一个一个地完成它们
In onion/hex architecture the outer layers should be independent from inner ones, but how is it implemented(please note my java/spring background)
对于架构模式，您会看到很多不同的解释，但这个让我觉得很奇怪。洋葱模式的内部部分是您的领域逻辑，而外部部分是其他领域或技术（数据库、网络服务……）的适配器。您不希望您的域依赖于这些技术细节，因此外部可能依赖于内部，但反之则不然。
In N-layered you auto-wire the N+1th layer components. I see the direction of the dependency, but how can you revert it:-/
这叫做控制反转。您的域（内部部分）经常需要调用适配器（例如您的数据库访问逻辑），因此在 运行 时间必须存在依赖关系。但是在编译时你不想要这样的依赖，以便能够替换所使用的特定技术。您可以通过使用接口和依赖注入来做到这一点。示例：您的域可能需要访问所有品牌的列表。为此，您创建一个如下所示的界面：
public interface BrandRepository{
public Set[Brand] all()
}
此界面是您域的一部分。您当然有该接口的实现，可能基于 Jdbc（或内存列表或 Web 服务）。此实现位于洋葱的外层。由于接口的实现依赖于内部，正如所要求的那样。
If I'm about to call outer layer, I will use interface. So the interface is in inner and implementation in outer layer. Now I'm independent on outer. This is it?
是
It is just about where the API is placed?
很难回答：你的API是什么？您的域模型是适配器的 API。适配器是您系统或其他系统的其他部分的API。
Anyway the hex/onion should be independent from dependency resolution, so does it mean I should not use @Autowire, @Inject etc??
现在可以争论一个世纪了。严格来说，这些注释依赖于您的 DI 框架。但是，由于这些得到了标准化，它们变得更加依赖于您的语言（如果不进入无限递归并收集大量语言设计经验，您将无法避免）。对注释的依赖，根据定义不能包含任何实现，这不是什么大问题，我个人对在我的代码中使用它们感到满意。
What I don't see is what is the difference(implementation) from n-layer structure.
洋葱结构是 n 层架构这一相当笼统的术语的特定变体。