DEV Community 👩‍💻👨‍💻

Cover image for Inverted Architecture: Taming dependencies
R.G. Lefever for DisComCo

Posted on • Updated on

Inverted Architecture: Taming dependencies



In a previous article, we explored N-tier architecture and discovered that this style has quite a number of shortcomings.
The most important being poor dependency control and extensive mapping due to its layered nature.
Over the years, many attempts have been made as to avoid these drawbacks, resulting in a number of alternatives that are known as Ports and Adapters, Onion- and also Hexagonal Architecture, just to name a few.

Inverting Control

Inverted Architecture

All these styles have in common that they are based on the principle of inversion of control. So, instead of creating a direct dependency on some infrastructure component, an adapter is created that implements an interface that is defined in a deeper shell, thus forcing dependencies to point inwards, towards the center.
The picture above depicts this principle nicely.

A brief explanation

At the center of our 'onion' sits the data model, which is usually just a collection of POxOs (Plain Old Objects) that represent the static data structures.

The domain shell is where the business logic is implemented, this may be simple business rules that govern data and its relationships for the model, but it may also implement behavior, depending on whether the context is data- or behavior-oriented respectively.
This is an important choice and deserves its own article, because it determines the scalability, extensibility and certainly also the availability of the system, as we will see in the next chapter.

The outer shell contains the drivers (or adapters) that attach to the infrastructure and implements interfaces (or ports) that are declared in the more inward domain shell.
Now, we do understand that this is a rather simplified depiction of more elaborate manifestations of the same principle. We invite the reader to investigate readily available sources if they seek more detail. However, for our purpose, this model is sufficient.

Improved Dependency Control

It is obvious that this kind of architecture improves drastically on the topic of dependency control, as compared to the previously discussed Layered form. In fact, this style prohibits by design that a deeper shell would address some infrastructure component directly, since it has no knowledge of it at all! Additionally, this form of architecture also allows us to swap technologies easily. Want to replace the database service? No problem, just write an adapter for it that implements the interface and voila!, you are good to go.

Improved Quality Assurance

Since the model- and domain shells have no dependencies on any infrastructure elements, this architectural style allows and even promotes early testing and test-driven development, without the need to introduce the additional complexity of 'mocking' infrastructure. In fact, business logic is isolated by design and can be tested as such.

Difficulty to Implement

Though Inverted Architecture does require a slight change in thinking, it would be too strong to say that it is more difficult to implement than the Layered form. One could even argue that it is simpler, because it frees the developers from concerns about dependency control and greatly simplifies testing practices.

Open Concerns

Though the various manifestations of Inverted Architecture address and solve some important concerns about dependency- and quality control and thus, maintainability, there still is room for improvement when it comes to extensibility and scalability. Small changes still propagate through all shells and for scalability, it is usually necessary to run multiple instances side by side. A solution to these concerns involves slicing up the onion into autonomous, decoupled components, a topic on which we will elaborate in the next article.


Inverted Architecture - Scorecard

Thank you for your time and as always, any questions, remarks and further discussions are encouraged and appreciated!

Top comments (0)

🌚 Browsing with dark mode makes you a better developer by a factor of exactly 40.

It's a scientific fact.