通过洋葱架构实现基础设施移动性 - 实际意义

Question

Onion 架构提供的主要优势之一是能够交换“基础设施”元素，例如“数据访问、I/O 和 Web 服务”( http://jeffreypalermo.com/blog/the-onion-architecture ) -第3部分/）。

Jeff 在 2008 年的帖子中表示，“业界至少每三年就会修改一次数据访问技术”。

有没有人有一个相当大的项目的例子，其中使用了洋葱架构并随后更换了关键基础设施元素？

我有兴趣了解：

• 一般来说，这种情况有多常见？

我的直觉告诉我，虽然“数据访问技术”可能每三年修改一次，但对运行解决方案的实际基础设施进行更改（这将使实现这一好处）的频率可能要低得多？

• 该解决方案最初运行的条件是什么？
• 是什么导致了底层基础设施的变化？
• 关于以这种方式改变基础设施的实际影响是否可以吸取教训，这可能使我们能够改进洋葱架构的原始实现？

我很想知道除了更换基础设施组件和实现相同的接口之外是否还需要进行意外的更改。例如，当从关系数据库模型迁移到 NoSQL DB 模型时，新基础设施是否需要将新参数传递给先前定义的方法，例如 SaveOrder(int ID) -> SaveOrder(int ID, bool AllowSiblings, bool SiblingCreated)。

• 与传统的耦合方法相比，这种架构的实施+重新设计以迁移到新的基础设施是否显着减少了所需的总工作量？

• 开发人员是否发现耦合的、硬引用的代码比松散耦合的、间接引用的代码更容易编写和调试，但基础设施更改的最终回报使这值得吗？

Answer 1

嗯，恕我直言，这种架构风格（Hexagoanl、Ports&Adapters、Onion \xe2\x80\xa6）的主要目的是它允许您专注于您的领域、如何交付价值，而不是首先关注 UI、框架或存储问题。它允许您推迟此类决定。

\n\n

正如杰弗里所说，交换“基础设施”元素的能力是这种架构风格的一个很好的副作用。即使您不会每 6 个月从一种 RDBMS 切换到另一种 RDBMS，但知道可以毫无痛苦地做到这一点，这还是相当令人放心的。

\n\n

不要考虑定期更改存储机制，或者像您所说的 \xe2\x80\x9c 交换关键基础设施元素\xe2\x80\x9d，而只需考虑您\xe2\x80\x99d 插入的第三方服务你的系统。那些渴望定期改变的人；您还可以从一个提供商切换到另一个提供商。这是我们经常遇到的更常见的情况。在这种特殊情况下，域行为不会改变，接口将保持不变，您不必将一行代码更改到核心域层中。只有基础设施层中某处的实现可能需要改变。\xe2\x80\x99 是这种架构的另一个值得注意的好处！

\n\n

请阅读鲍勃叔叔这篇精彩的文章，他解释了为什么推迟关键基础设施决策的能力真的很酷！

\n\n

- - 编辑 - -

\n\n

您能否提供一个更换第三方服务的示例？

\n\n

我们有大量从一个提供商切换到另一个提供商的例子（从支付提供商到实时提要提供商或任何提供商）。业务保持不变，领域行为也保持不变。更换提供商不应对您的业务产生任何影响。您不必改变业务的运作方式，而业务的真正价值就在于此，仅仅因为您从一个提供商更换为另一个提供商，这是没有意义的。将您的领域行为隔离在独立的核心层中，不依赖于任何第三方库、框架或提供商服务，绝对可以帮助您应对变化。

\n\n

我有一种感觉，你\xe2\x80\x99正在试图说服自己是否选择洋葱。您可能走错了路，只考虑迁移到新的基础设施相关的东西（数据库、第三方的东西.​​.....）。相反，请专注于您的领域。问问自己，您的领域是否足够复杂，需要这样的架构风格。不要\xe2\x80\x99t 使用火箭筒杀死苍蝇。正如西蒙·布朗所说：“原则是好的，但要确保它们\xe2\x80\x99是现实的，并且不会\xe2\x80\x99产生负面影响”！

\n\n

如果你的应用程序很小，没有复杂的业务领域，那么选择经典的n层架构，\xe2\x80\x99就可以了；不要仅仅为了改变事物或仅仅因为任何流行语而改变事物。但还要记住，没有依赖关系的独立核心业务层（如洋葱架构中）可能非常容易进行单元测试！

\n\n

现在回答您的其他问题：

\n\n

与传统的耦合方法相比，这种架构的实施+重新设计以迁移到新的基础设施是否显着减少了所需的总工作量？

\n\n

这取决于！:-) 在紧密耦合的应用程序中，一旦有新的基础架构元素需要迁移，毫无疑问，您肯定必须修改每个层（包括业务层）中的代码）。但是，如果这个应用程序很小，非常简单，组织良好，并且具有下降测试代码覆盖率，那么\xe2\x80\x99应该不是什么大问题。现在，如果它\xe2\x80\x99相当大，具有更复杂的业务领域，那么将该层隔离在完全独立的层中可能是一个好主意，根本没有依赖关系，确保基础设施更改不会\xe2\x80 \x99t 不会导致任何业务倒退。

\n\n

开发人员是否发现耦合的、硬引用的代码比松散耦合的、间接引用的代码更容易编写和调试，但基础设施更改的最终回报使这值得吗？

\n\n

那就问问你的队友吧！他们习惯与国际奥委会合作吗？请记住，架构设计和选择必须是团队决策。这一定是整个团队共同的事情。

\n