通过洋葱架构实现基础架构的移动性-实际意义 [英] Infrastructure mobility via Onion architecture - practical implications

问题描述

Onion体系结构提供的主要优势之一是能够交换基础结构"元素，例如数据访问，I/O和Web服务"(

One of the key benefits provided by Onion architecture is the ability to swap out "infrastructure" elements, such as "Data Access, I/O, and Web Services" (http://jeffreypalermo.com/blog/the-onion-architecture-part-3/).

Jeff在2008年的帖子中说:该行业至少每三年就修改一次数据访问技术."

Jeff says in his post from 2008 that "the industry has modified data access techniques at least every three years".

有没有人举一个使用洋葱架构并随后进行关键基础架构元素交换的大型项目的例子?

Does anyone have an example of a reasonably large project where Onion architecture was used and swapping out of key infrastructure elements was subsequently undertaken?

我有兴趣了解:

• 一般来说，这种情况有多普遍?

我的直觉告诉我，虽然数据访问技术"可能每三年进行一次修改，但是对运行解决方案的实际基础架构进行更改(使这种好处得以实现)的频率可能要低得多?

My instinct tells me that while "data access techniques" may be modified every three years, changes to actual infrastructure for running solutions, which would allow this benefit to be realised, may be a lot less frequent?

• 该解决方案最初在什么条件下运行?
• 是什么原因导致基础架构发生了变化?
• 是否需要学习有关以这种方式更改基础架构的实际含义的课程，这可能使我们可以完善Onion体系结构的原始实现?

我很想知道是否需要进行意想不到的更改，而不仅仅是更换基础架构组件并实现相同的接口.例如，新的基础架构是否要求将新的参数传递给先前定义的方法，例如从关系型迁移到NoSQL数据库模型时，SaveOrder(int ID)-> SaveOrder(int ID，布尔AllowSiblings，布尔SiblingCreated).

I'm interested to hear whether there were unexpected changes required beyond just replacing the infrastructure component and implementing the same interface. For example, did the new infrastructure require new arguments to be passed to previously defined methods e.g. SaveOrder(int ID) -> SaveOrder(int ID, bool AllowSiblings, bool SiblingCreated) when moving from a Relational to NoSQL DB model.

• 与传统的耦合方法相比，实施此体系结构+进行重新部署以迁移到新的基础架构是否会大大减少所需的总工作量?

• Did the implementation of this architecture + rework to migrate to new infrastructure significantly decrease the total effort required, if compared to a traditional, coupled approach?

开发人员是否发现耦合的，硬引用的代码比松散耦合的，间接引用的代码更容易编写和调试，但是最终因基础结构更改而获得的回报值得吗?

Do developers find coupled, hard-referenced code easier to write and debug than loosely coupled, indirectly referenced code, but the eventual payoff for infrastructure changes makes this worth it?

推荐答案

嗯，恕我直言，这种体系结构样式(Hexagoanl，Ports& Adapters，Onion…)的主要目的是让您专注于自己的领域，如何您将交付价值，而不是首先关注UI，框架或存储问题.它使您可以推迟此类决定.

Well, IMHO, the primary intent of such architecture style (Hexagoanl, Ports&Adapters, Onion …) is that it allows you to focus on your domain, how you will deliver value instead of focusing first on UI, frameworks or storage issues. It allows you to defer such decisions.

正如Jeffrey所说，交换基础结构"元素的能力是这种体系结构样式的一个很好的副作用.即使您不会每六个月从一个RDBMS切换到另一个RDBMS，也可以放心地做到这一点，这确实令人放心.

As Jeffrey says, the ability to swap out "infrastructure" elements is a nice side effect of such architecture style. Even if you will not switch from one RDBMS to another every 6 months, it’s quite reassuring knowing that it would be possible doing it without pain, though.

与其考虑定期更改存储机制，也不如您所说的交换关键​​基础架构元素"，而是考虑要插入系统的第三方服务.那些渴望定期改变的人；您还将从一个提供程序切换到另一个提供程序.这是我们经常要面对的非常普遍的情况.在这种情况下，域行为不会改变，界面将保持不变，您不必在核心域层中更改一行代码.只有在您的基础结构层中某个地方进行的实现可能需要更改.这种架构的另一个值得一提的好处！

Rather than thinking about changing your storage mechanism on a regular basis or as you said "swapping out of key infrastructure elements", just think about third parties services that you’d plug to your system. Those are eager to change on a regular basis; you would also switch from one provider to another. This is quite a more common scenario we are used to face with on a more regular basis. In this particular case, the domain behavior won’t change, the interfaces will stay the same, you won’t have to change a single line of code into your core domain layer. Only the implementation made somewhere in your infrastructure layer might have to change. That’s a another noteworthy benefit from that kind of architecture!

请阅读这篇鲍勃叔叔的好文章关于清洁架构"，他解释了为什么推迟关键基础架构决策的能力真的很酷！

Please read this nice Uncle Bob article about Clean Architecture where he explains why the ability to defer critical infrastructure decision is really cool!

---编辑---

您能否提供一个示例，说明您在哪里交换了第三方服务?

我们有无数的示例，其中我们从一个提供程序切换到另一个提供程序(从付款提供程序更改为实时供稿提供程序或任何提供程序).业务保持不变，域行为仍然相同.更换供应商不会对您的业务产生任何影响.您不必改变业务运作的方式(真正的价值所在)，仅因为您从一个提供商变成另一个提供商，就没有任何意义.将您的域行为隔离在一个独立的核心层中，而不依赖于任何第三方库，框架或提供程序服务，绝对可以帮助您应对更改.

We have tons of examples where we switched from one provider to another (from payment providers to live feeds providers or whatever provider). The business stays the same, the domain behaviors are still the same. Changing a provider should not have any kind of impact on your business. You don’t have to change the way your business work, where the value really is, just because you change from one provider to another, it makes no sense. Isolating your domain behaviors in an independent core layer, with no dependencies on any third parties libraries, frameworks or provider services, definitely help you to deal with changes.

我有种感觉，您正在尝试说服自己是否应该选择洋葱.您可能只在考虑迁移到新的与基础架构相关的内容(数据库，第三方内容...)而走错了路.专注于您的域.问问自己，您的领域是否足够复杂以至于需要这种架构样式.不要使用火箭筒杀死苍蝇.正如西蒙·布朗所说:"原则是好的，但要确保它们是现实的并且没有负面影响"！

I have the feeling that you’re trying to convince yourself whether to go with Onion. You might be on the wrong track only thinking about migrating to new infrastructure related stuff (db, third parties stuff...). Focus on your domain instead. Ask yourself if your domain is complex enough to require such an architecture style. Don’t use a bazooka to kill a fly. As Simon Brown says: "Principles are good, but make sure they’re realistic and don’t have a negative impact"!

如果您的应用程序非常小，没有复杂的业务领域，则可以使用经典的n层体系结构；不要仅仅为了它或仅仅因为流行词而改变事物.但也要记住，像洋葱架构中那样，没有依赖关系的孤立的核心业务层可能非常容易进行单元测试！

If your application is quite small, with no complex business domain, go for classic n-tiers architecture, that’s ok; don’t change things just for the sake of it or just because of any buzzword. But also keep in mind that an isolated core business layer without dependencies, as in Onion architecture, might be very easy to unit test!

现在有其他问题:

与传统的耦合方法相比，实施此体系结构+进行重新工作以迁移到新的基础架构是否会大大减少所需的总工作量?

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

It depends! :-) In tightly coupled applications as soon as there’s a new infrastructure element to be migrated, there is little doubt that you’ll surely have to modify code in every layers (including the business layer). But if this application is small, quite straightforward, well organized with a descent test code coverage, this shouldn’t be a big deal. Now, if it’s quite big, with a more complex business domain, it might be a good idea to isolate that layer in a totally separate layer with no dependencies at all, ensuring that infrastructure changes won’t cause any business regression.

开发人员是否发现耦合的，硬引用的代码比松散耦合的，间接引用的代码更容易编写和调试，但是最终因基础结构更改而获得的回报值得吗?

好吧，问问你的队友！他们曾经与IOC合作吗?请记住，架构设计和选择必须是团队的决定.这必须是整个团队的共同点.

Well, ask your teammates! Are they used to work with IOC? Remember that architecture design and choices must be a team decision. This must be something shared by the whole team.

这篇关于通过洋葱架构实现基础架构的移动性-实际意义的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！