Sliced Onion Architecture

Hi,

A week ago, Oliver Drotbohm published an expanded idea of the Onion Architecture: The Sliced Onion Architecture .

Most software developers are familiar with Hexagonal Architecture and its extension, the Onion Architecture . The idea (simplified): One decouples their business code from infrastructure code using adapters.

This makes it less likely to create the “Big Ball of Mud” .

What do I see in practice?

Most developers have understood that it’s a good idea not to mix business code with infrastructure code.

At the same time, they want to distribute their application. Often for the wrong reasons - but that’s another story.

When the application is distributed, a communication component is needed. And if communication is regular, decoupling with a message queue is needed.

The idea from Oliver is directed at this point. We no longer see our individual domains as a complete onion. It is allowed that the application layers can communicate directly with each other.

In practice, this is simply a method call or an internal event messaging mechanism like Spring’s ApplicationEvents.

This is simple.

At the same time, we have the freedom to cut our application in the future and deploy independently.

Without having a name for it, I have been developing my applications with this idea for years. It is the visualization I didn’t know I needed.

Thank you, Oliver!

Rule the Backend, ~ Marcus