>>>Hello, I am working on an older project that needs to be maintained, however most of the existing code is suboptimal and difficult to add functionality. So what I am doing is to decide on a per case basis whether it is OK to just do the changes in teh existing code (mostly when it is a minor Change), or sometimes to redesign and build better reusable parts to replace the old design. I understand that this is an anti-pattern that is called Onion, but what confuses me is that sometimes the Onion is regarded as a negative design, while in other places it is considered a good solution.
>>>
>>>Would the answer be "It depends" (to the question if this pattern is OK to use or not) or are there real pitfalls I need to be aware of when implementing those onion layers?
>>
>>
>>onion architecture pattern : good
>>onion programming anti-pattern : bad
>
>Thanks for clarifying, that was my confusion between those two.
>
>Now I have a follow up question: what I am dealing with in my case is definitely the anti-pattern. But how could I possibly avoid it? Either I reproduce the bad code and write more bad code which increases the technical debt, or I do the anti-pattern, which apparently is also not the correct thing to do? Complete redesign is too time consuming and what is the better option in the end?

You always have to figure out how someone else's code works. Better to replace old code with your new code, especially if it involves new and better practices. Think of it this way - you have a working 1965 Chevy Impala. Part of it is rusting badly. What you do is cut out the rusting part and replace that with new metal. It's a patchwork, but it's a patch that actually solved the underlying problem. You do not cover it up - onion anti-pattern. Patchwork is a bad approach if you put new metal in the midst of the rusting metal. The new patch will fall off if it sticks at all.