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

Question

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

Jeff 在 2008 年的帖子中说，“该行业至少每三年修改一次数据访问技术”。

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

我有兴趣了解：

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

我的直觉告诉我，虽然“数据访问技术”可能每三年修改一次，但运行解决方案的实际基础架构的更改（这将使这一好处得以实现）可能会少很多？

• 解决方案最初的运行条件是什么？
• 是什么导致底层基础架构发生变化？
• 对于以这种方式改变基础架构的实际影响，是否有经验教训可以让我们改进 Onion 架构的原始实现？

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

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

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

Answer 1

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

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

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

请阅读 this nice Uncle Bob article 关于清洁架构的内容，他解释了为什么推迟关键基础架构决策的能力真的很酷！

--- 编辑---

您能否举例说明您在哪里更换了第三方服务？

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

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

如果您的应用程序很小，没有复杂的业务领域，请选择经典的 n 层架构，没关系；不要仅仅为了它或仅仅因为任何流行语而改变事情。但也要记住，没有依赖关系的独立核心业务层，如 Onion 架构，可能很容易进行单元测试！

现在有其他问题：

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

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

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

好吧，问问你的队友！他们习惯与国际奥委会合作吗？请记住，架构设计和选择必须由团队决定。这必须是整个团队共享的东西。