why to avoid onion-like architectures

first things first, it is important for us to understand what onion-like stands for.

just like an onion, an architecture must have a lot of layers, but, at some point, the excess of layers may make the project be hard to maintain or have a poor performance.

the hexagonal issue

the hexagonal arch is known for being a well designed and resilient architecture, but, it have some serious issues.

almost every one of them issues are related to the amount of processes and changes that you need to perform in order to maintain that architecture.

let me give you an example: if you are willing to create an easy back-end application that must only feed some information to your front-end application without a lot of permissions or data parsing, you must go with the simpler approach possible.

but, let us imagine that you go and do a bad take and choose a ports & adapters architecture for this application that is supposed to be as simple as possible.

your first issues probably will be:

• you will need to create a protocol for every one of your requests and make them resilient for other approaches, such as cli commands or webhooks
• type inconsistencies: if you do not use a language that allows you to explicit types and create a type-safe application, you probably will suffer from inconsistencies between the layers of your application
• amount of files needed to be changed in order to perform an endpoint rule change

I know that other problems may rise or some of the problems of the list above can be avoided using DTOs and other parsing features, but, would not it be easier if you just chose to use a simpler architecture since the start of the project?

taking the right option

it is not right to tell someone that a specific architecture will solve every structural problem, but, you need to have something in mind when you are thinking about architecture: its main purpose is to solve organizational problems, so, do not try to create more of them.

if you need to solve a small problem with a small crew, you must use a small and fast architecture

if you are willing to solve a complex problem with a larger and more mature crew, you must use an architecture that will be reliable for your infrastructure.

---

Photo by Nick Andréka on Unsplash

Comments

[Alexander Girke]

From the headline, I thought I would completely disagree. But your recommendation regarding small teams is of course a totally valid one. Have you heard of the sliced onion architecture? Seems to be a good middleground between well-structured, domain-driven architectures & start-up-like simple architectures.