Onion架构提供的一个主要优势是能够交换“基础架构”元素，例如“数据访问，I / O和Web服务”（http://jeffreypalermo.com/blog/the-onion-architecture-part-3/）。
杰夫在2008年的帖子中说，“该行业至少每三年就修改一次数据访问技术”。
有没有人有一个相当大的项目的例子，其中使用了洋葱架构并随后进行了关键基础设施元素的交换？
我有兴趣了解：
我的直觉告诉我，虽然“数据访问技术”可能每三年进行一次修改，但运行解决方案的实际基础设施的变化（这样可以实现这一好处）可能会少得多吗？
我很想知道除了更换基础架构组件和实现相同的界面之外是否还需要进行意外更改。例如，新的基础设施是否需要将新参数传递给先前定义的方法，例如SaveOrder（int ID） - ＆gt;从Relational迁移到NoSQL DB模型时，SaveOrder（int ID，bool AllowSiblings，bool SiblingCreated）。
与传统的耦合方法相比，迁移到新基础架构的此架构+返工的实施是否显着减少了所需的总工作量？
开发人员是否发现耦合的，硬引用的代码比松散耦合的，间接引用的代码更容易编写和调试，但基础设施更改的最终回报是否值得呢？
答案 0 :(得分：3)
嗯，恕我直言，这种架构风格的主要目的（Hexagoanl，Ports＆amp; Adapters，Onion ......）是它允许您专注于您的域，如何提供价值而不是首先关注UI，框架或存储的问题。它允许您推迟这样的决定。
正如杰弗里所说，能够换掉“基础设施”元素是这种架构风格的一个很好的副作用。即使你不会每6个月从一个RDBMS切换到另一个RDBMS，但是知道可以毫无痛苦地做到这一点是非常令人放心的。
不要考虑定期更改存储机制，也不要考虑“更换关键基础架构元素”，只需考虑要插入系统的第三方服务。那些人渴望定期改变;你也会从一个提供商切换到另一个提供商。这是我们过去经常面对的一种更常见的情况。在这种特殊情况下，域行为不会改变，接口将保持不变，您不必将一行代码更改为核心域层。只有在基础架构层中某处实现的实现可能必须更改。这是这种架构的另一个值得注意的好处！
请阅读有关清洁架构的this nice Uncle Bob article，他解释了为什么推迟关键基础架构决策的能力真的很酷！
---编辑---
您能举例说明您换出第三方服务的位置吗？
我们有很多例子，我们从一个提供商切换到另一个提供商（从支付提供商到实时提供商或任何提供商）。业务保持不变，域行为仍然相同。更改提供商不应对您的业务产生任何影响。您不必改变业务工作方式，价值确实存在，只是因为您从一个提供商转换到另一个提供商，这没有任何意义。在独立的核心层中隔离您的域行为，不依赖于任何第三方库，框架或提供者服务，绝对可以帮助您处理更改。
我觉得你试图说服自己是否要和洋葱一起去。你可能在错误的轨道上只考虑迁移到新的基础设施相关的东西（db，第三方的东西......）。专注于您的域名。问问自己，您的域名是否足够复杂，需要这样的架构风格。不要用火箭筒杀死苍蝇。正如Simon Brown所说：“原则很好，但要确保它们是现实的，不会产生负面影响”！
如果您的应用程序非常小，没有复杂的业务领域，请选择经典的n层架构，这没关系;不要仅仅因为它或仅仅因为任何流行语而改变事物。但是请记住，像Onion架构一样，没有依赖关系的孤立核心业务层可能非常容易进行单元测试！
现在提出您的其他问题：
与传统的耦合方法相比，迁移到新基础架构的此架构+返工的实施是否显着减少了所需的总工作量？
这取决于！ :-)在紧密耦合的应用程序中，只要有一个新的基础架构元素要迁移，毫无疑问你必须修改每个层（包括业务层）中的代码。但是，如果这个应用程序很小，很简单，组织良好，下降测试代码覆盖率，这应该不是什么大问题。现在，如果它非常大，拥有更复杂的业务领域，那么将该层隔离在一个完全独立的层中并且根本没有依赖关系可能是一个好主意，确保基础架构更改不会导致任何业务回归。
开发人员是否发现耦合的，硬引用的代码比松散耦合的，间接引用的代码更容易编写和调试，但基础设施变更的最终回报是否值得呢？
好吧，问问你的队友！他们习惯与IOC合作吗？请记住，架构设计和选择必须是团队决策。这必须是整个团队共享的东西。