>>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?