Infrastructure mobility through bow architecture - practical implications

Question

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

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

Does anyone have an example of a large enough project that used Onion architecture and subsequently replaced the replacement of key infrastructure elements?

I am interested to understand:

• How common is this scenario in general?

My instinct tells me that although “data access methods” can be changed every three years, changes in the real infrastructure for launching solutions that would realize this benefit can be much less common?

• What were the conditions due to which the decision was initially implemented?
• What caused the change in underlying infrastructure?
• Are there any lessons to be learned from the practical implications of changing the infrastructure in a way that can allow us to refine the original Onion architecture implementations?

I am interested to know if there were unexpected changes needed only to replace the infrastructure component and implement the same interface. For example, for a new infrastructure to require passing new arguments to previously defined methods, for example. SaveOrder (int ID) → SaveOrder (int ID, bool AllowSiblings, bool SiblingCreated) when switching from the NoSQL relational database model.

• Has this architecture been implemented + reworked to transition to a new infrastructure, significantly reducing the total required workload compared to the traditional approach associated with this?

• Are developers helping to find linked, hard link code easier to write and debug than loosely linked, indirect link code, but is the potential gain for infrastructure changes worth it?

Answer 1

Well, IMHO, the main purpose of this style of architecture (Hexagoanl, Ports & Adapters, Onion ...) is that it allows you to focus on your domain, how you will provide value instead of focusing on the user interface, infrastructure or repository issues. This allows you to delay the adoption of such decisions.

According to Jeffrey, the ability to change elements of infrastructure is a good side effect of this style of architecture. Even if you don't switch from one RDBMS to another every 6 months, her quite soothing knowledge that you could do it without pain.

Instead of thinking that you regularly change your storage mechanism or, as you said, “replace key infrastructure elements”, just think about the third-party services that you connect to your system. Those who want to change regularly; You will also switch from one provider to another. This is a fairly common scenario that we are used to encountering on a more regular basis. In this particular case, the domain behavior will not change, the interfaces will remain unchanged, you will not have to change one line of code to your main domain level. You may need to change only the implementation performed somewhere in your infrastructure layer. This is another noteworthy advantage of this architecture!

Please read this cute Uncle Bob article on clean architecture, where he explains why the ability to put off a critical infrastructure situation is really cool!

--- EDIT ---

Could you give an example of where you changed your third-party service?

We have many examples when we switched from one provider to another (from payment providers to live feed providers or any other provider). Business remains the same, domain behavior remains the same. Changing the supplier should not have any impact on your business. You do not need to change the way your business works, where it really is, simply because you are changing from one provider to another, it makes no sense. Insulating your domain’s behavior at a separate base level without any dependencies on any third-party libraries, frameworks or service providers will certainly help you cope with the changes.

I have a feeling that you are trying to convince yourself whether to go with a bow. Perhaps you are mistaken, thinking only about the transition to a new infrastructure (db, third-party things ...). Instead, focus on your domain. Ask yourself if your domain has enough complex architectural style. Do not use a bazooka to kill a fly. As Simon Brown says: "The principles are good, but make sure they are realistic and have no negative impact!"

If your application is quite small, without any complex business domain, go for the classic n-tier architecture, that's fine; don't change things just for the sake of it or just because of some buzzword. But also keep in mind that an isolated, independent, core business layer without dependencies, like in Onion architecture, can be very easy for unit test!

Now for your additional questions:

Is the implementation of this architecture + rework implemented for the transition to a new infrastructure, significantly reducing the total required load compared to the traditional, related approach?

It depends! :-) In closely related applications, as soon as the new infrastructure element is ported, there is no doubt that you will definitely have to modify the code in all layers (including the business layer). But if this application is small, fairly simple, well-organized with coverage of the descent test code, this should not be a big problem. Now, if its quite large, with a more complex business domain, it might be a good idea to isolate this layer on a completely separate level without any dependencies at all, ensuring that changes in the infrastructure will not cause any business regression.

Are developers helping to find linked, hard link code easier to write and debug than loosely linked, indirect link code, but is the potential gain for infrastructure changes worth it?

Ok, ask your teammates! Are they used to work with the IOC? Remember that design and architecture choices must be a team decision. It should be something common for the whole team.