基础的流动性 - 实际影响

Question

一个由洋葱架构所提供的主要优点是换出“基础设施”的元素，如“数据访问，I/O和网络服务”（http://jeffreypalermo.com/blog/the-onion-architecture-part-3/）的能力。

杰夫说，在他的岗位从2008年说，“行业已经修改的数据访问技术每三年至少”。

有没有人有一个相当大的项目的例子，其中使用洋葱结构和换出关键的基础设施要素随后被承担？

我有兴趣了解：

• 如何常见的是这种情况下，有什么看法？

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

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

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

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

• 开发者是否发现耦合的，硬引用的代码比松散耦合的，间接引用的代码更易于编写和调试，但基础架构更改的最终收益是否值得呢？

Answer 1

嘛，恕我直言，这样的建筑风格（Hexagoanl，港口&适配器，洋葱...）的主要目的是，它可以让你专注于自己的领域，你将如何，而不是实现重点首先是UI的价值，框架或存储问题。它允许你推迟这样的决定。

正如杰弗里所说，换出“基础设施”元素的能力是这种架构风格的一个很好的副作用。尽管你不会每隔6个月从一个关系数据库切换到另一个关系关系数据库，但是我们知道尽可能无痛苦地完成这个任务是非常令人放心的。

不是想着定期更改您的存储机制或如你所说的“关键基础设施部件的换出”相反，想想第三方服务，你会堵塞你的系统。那些渴望定期改变的人;你也可以从一个提供者切换到另一个提供者。这是我们习惯于更经常地面对的一种更常见的情况。在这种特殊情况下，域行为不会改变，接口将保持不变，您不必将单行代码更改为核心域层。只有在基础架构层中的某个实现可能需要更改。这是来自这种架构的另一个值得注意的好处！

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

---编辑---

你能提供的，你必须换出第三方服务的例子吗？

我们有很多例子，我们从一个提供者切换到另一个提供者（从支付提供者到活动提供者或任何提供者）。业务保持不变，领域行为仍然相同。更改提供商不应对您的业务产生任何影响。您不必改变您的业务运作方式，价值的确切位置，仅仅因为您从一个供应商变为另一个供应商，这是没有意义的。在独立的核心层中隔离您的域行为，不依赖于任何第三方库，框架或提供者服务，绝对有助于您应对更改。

我有这样的感觉，你试图说服自己是否要去洋葱。你可能只是在考虑迁移到新的基础设施相关的东西（数据库，第三方的东西.​​.....）。改为关注你的域名。问问你自己，如果你的域名足够复杂，需要这样的架构风格。不要使用火箭筒杀死苍蝇。由于Simon Brown说：“原则是好的，但要确保它们是现实的，没有负面影响”！

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

现在您还有其他问题：

难道这种架构+实施返工迁移到新的基础设施显著减少所需的总工作量，如果相对于传统，耦合方法？

这要看！ :-)在紧密耦合的应用程序中，只要有一个新的基础架构元素需要迁移，毫无疑问，您肯定必须修改每个层（包括业务层）中的代码。但是，如果这个应用程序很小，很简单，组织良好，并且有一个下降测试代码覆盖率，这应该不是什么大问题。现在，如果它相当大，并且业务领域更加复杂，那么将这一层分离成完全独立的层并且完全不存在依赖关系可能是一个好主意，这样可以确保基础架构更改不会导致任何业务回归。

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

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