通过洋葱架构实现基础设施移动性——实际意义
Infrastructure mobility via Onion architecture - practical implications
Onion 架构提供的主要优势之一是能够换出 "infrastructure" 元素，例如 "Data Access, I/O, and Web Services" (http://jeffreypalermo.com/blog/the-onion-architecture-part-3/)。
杰夫在 2008 年的 post 中说 "the industry has modified data access techniques at least every three years"。
有没有人举过一个相当大的项目的例子，其中使用了 Onion 架构并随后进行了关键基础设施元素的交换？
我有兴趣了解：
- 一般来说，这种情况有多常见？
我的直觉告诉我，虽然 "data access techniques" 可能每三年修改一次，但 运行 解决方案的实际基础架构的更改频率可能要低得多？
- 解决方案最初运行的条件是什么？
- 是什么导致了底层基础设施的变化？
- 关于以这种方式改变基础设施的实际影响，是否可以吸取教训，这可能使我们能够改进洋葱架构的原始实现？
我很想知道除了替换基础结构组件和实现相同接口之外是否还需要进行意想不到的更改。例如，新的基础设施是否需要将新参数传递给先前定义的方法，例如SaveOrder(int ID) -> SaveOrder(int ID, bool AllowSiblings, bool SiblingCreated) 当从关系数据库模型移动到 NoSQL 数据库模型时。
与传统的耦合方法相比，此架构的实施 + 迁移到新基础架构的返工是否显着减少了所需的总工作量？
开发人员是否发现耦合的、硬引用的代码比松散耦合的、间接引用的代码更容易编写和调试，但基础架构更改的最终回报是否值得？
嗯，恕我直言，这种架构风格（Hexagoanl、Ports&Adapters、Onion …）的主要目的是让你专注于你的领域，你将如何交付价值而不是首先关注 UI 、框架或存储问题。它允许您推迟此类决定。
正如 Jeffrey 所说，交换 "infrastructure" 元素的能力 是这种架构风格的一个很好的副作用。即使您不会每 6 个月从一种 RDBMS 切换到另一种 RDBMS，但知道可以毫无痛苦地进行转换还是很令人放心的。
与其考虑定期更改存储机制或如您所说的“交换关键基础架构元素”，不如考虑插入系统的第三方服务。那些渴望定期改变；您还可以从一个提供商切换到另一个提供商。这是我们经常面对的更常见的情况。在这种特殊情况下，域行为不会改变，接口将保持不变，您不必更改核心域层中的一行代码。只有基础设施层某处的实现可能需要更改。这是这种架构的另一个值得注意的好处！
请阅读 this nice Uncle Bob article 关于 Clean Architecture 的文章，他解释了为什么推迟关键基础设施决策的能力真的很酷！
--- 编辑 ---
您能否举例说明您在何处更换了第三方服务？
我们有大量从一个供应商切换到另一个供应商的例子（从支付供应商到直播供应商或任何供应商）。业务保持不变，领域行为仍然相同。更换供应商不应对您的业务产生任何影响。你不必改变你的业务运作方式，真正有价值的地方，只是因为你从一个供应商改变到另一个供应商，这是没有意义的。将您的域行为隔离在一个独立的核心层中，不依赖于任何第三方库、框架或提供者服务，绝对可以帮助您应对变化。
我感觉你在试图说服自己是否选择 Onion。你可能走错了路，只考虑迁移到新的基础设施相关的东西（数据库，第三方的东西......）。而是专注于您的领域。问问自己，您的领域是否复杂到需要这种架构风格。不要使用火箭筒来杀死苍蝇。正如 Simon Brown 所说：“原则是好的，但要确保它们是现实的并且不会产生负面影响”！
如果你的应用程序很小，没有复杂的业务领域，那么选择经典的 n 层架构，没关系；不要仅仅为了它或仅仅因为任何流行语而改变事情。但也要记住，一个没有依赖关系的独立核心业务层，就像在洋葱架构中一样，可能很容易进行单元测试！
现在回答您的其他问题：
与传统的耦合方法相比，此架构的实施 + 迁移到新基础架构的返工是否显着减少了所需的总工作量？
视情况而定！ :-) 在紧密耦合的应用程序中，只要有一个新的基础设施元素要迁移，毫无疑问，您肯定必须修改每一层（包括业务层）的代码。但是，如果此应用程序很小，非常简单，组织良好且具有下降测试代码覆盖率，那么这应该不是什么大问题。现在，如果它非常大，具有更复杂的业务领域，那么将该层隔离在一个完全没有依赖关系的完全独立的层中可能是个好主意，确保基础架构更改不会导致任何业务回归。
开发人员是否发现耦合的、硬引用的代码比松散耦合的、间接引用的代码更容易编写和调试，但基础架构更改的最终回报是否值得？
好吧，问问你的队友吧！他们习惯于与国际奥委会合作吗？请记住，架构设计和选择必须由团队决定。这一定是整个团队共享的东西。
Onion 架构提供的主要优势之一是能够换出 "infrastructure" 元素，例如 "Data Access, I/O, and Web Services" (http://jeffreypalermo.com/blog/the-onion-architecture-part-3/)。
杰夫在 2008 年的 post 中说 "the industry has modified data access techniques at least every three years"。
有没有人举过一个相当大的项目的例子，其中使用了 Onion 架构并随后进行了关键基础设施元素的交换？
我有兴趣了解：
- 一般来说，这种情况有多常见？
我的直觉告诉我，虽然 "data access techniques" 可能每三年修改一次，但 运行 解决方案的实际基础架构的更改频率可能要低得多？
- 解决方案最初运行的条件是什么？
- 是什么导致了底层基础设施的变化？
- 关于以这种方式改变基础设施的实际影响，是否可以吸取教训，这可能使我们能够改进洋葱架构的原始实现？
我很想知道除了替换基础结构组件和实现相同接口之外是否还需要进行意想不到的更改。例如，新的基础设施是否需要将新参数传递给先前定义的方法，例如SaveOrder(int ID) -> SaveOrder(int ID, bool AllowSiblings, bool SiblingCreated) 当从关系数据库模型移动到 NoSQL 数据库模型时。
与传统的耦合方法相比，此架构的实施 + 迁移到新基础架构的返工是否显着减少了所需的总工作量？
开发人员是否发现耦合的、硬引用的代码比松散耦合的、间接引用的代码更容易编写和调试，但基础架构更改的最终回报是否值得？
嗯，恕我直言，这种架构风格（Hexagoanl、Ports&Adapters、Onion …）的主要目的是让你专注于你的领域，你将如何交付价值而不是首先关注 UI 、框架或存储问题。它允许您推迟此类决定。
正如 Jeffrey 所说，交换 "infrastructure" 元素的能力 是这种架构风格的一个很好的副作用。即使您不会每 6 个月从一种 RDBMS 切换到另一种 RDBMS，但知道可以毫无痛苦地进行转换还是很令人放心的。
与其考虑定期更改存储机制或如您所说的“交换关键基础架构元素”，不如考虑插入系统的第三方服务。那些渴望定期改变；您还可以从一个提供商切换到另一个提供商。这是我们经常面对的更常见的情况。在这种特殊情况下，域行为不会改变，接口将保持不变，您不必更改核心域层中的一行代码。只有基础设施层某处的实现可能需要更改。这是这种架构的另一个值得注意的好处！
请阅读 this nice Uncle Bob article 关于 Clean Architecture 的文章，他解释了为什么推迟关键基础设施决策的能力真的很酷！
--- 编辑 ---
您能否举例说明您在何处更换了第三方服务？
我们有大量从一个供应商切换到另一个供应商的例子（从支付供应商到直播供应商或任何供应商）。业务保持不变，领域行为仍然相同。更换供应商不应对您的业务产生任何影响。你不必改变你的业务运作方式，真正有价值的地方，只是因为你从一个供应商改变到另一个供应商，这是没有意义的。将您的域行为隔离在一个独立的核心层中，不依赖于任何第三方库、框架或提供者服务，绝对可以帮助您应对变化。
我感觉你在试图说服自己是否选择 Onion。你可能走错了路，只考虑迁移到新的基础设施相关的东西（数据库，第三方的东西......）。而是专注于您的领域。问问自己，您的领域是否复杂到需要这种架构风格。不要使用火箭筒来杀死苍蝇。正如 Simon Brown 所说：“原则是好的，但要确保它们是现实的并且不会产生负面影响”！
如果你的应用程序很小，没有复杂的业务领域，那么选择经典的 n 层架构，没关系；不要仅仅为了它或仅仅因为任何流行语而改变事情。但也要记住，一个没有依赖关系的独立核心业务层，就像在洋葱架构中一样，可能很容易进行单元测试！
现在回答您的其他问题：
与传统的耦合方法相比，此架构的实施 + 迁移到新基础架构的返工是否显着减少了所需的总工作量？
视情况而定！ :-) 在紧密耦合的应用程序中，只要有一个新的基础设施元素要迁移，毫无疑问，您肯定必须修改每一层（包括业务层）的代码。但是，如果此应用程序很小，非常简单，组织良好且具有下降测试代码覆盖率，那么这应该不是什么大问题。现在，如果它非常大，具有更复杂的业务领域，那么将该层隔离在一个完全没有依赖关系的完全独立的层中可能是个好主意，确保基础架构更改不会导致任何业务回归。
开发人员是否发现耦合的、硬引用的代码比松散耦合的、间接引用的代码更容易编写和调试，但基础架构更改的最终回报是否值得？
好吧，问问你的队友吧！他们习惯于与国际奥委会合作吗？请记住，架构设计和选择必须由团队决定。这一定是整个团队共享的东西。