Well but that is the normal course even if the project has all the time in the world, because you only know what you know at the time of conception and implemen

Well but that is the normal course even if the project has all the time in the world, because you only know what you know at the time of conception and implementation and software always ends up describing complex systems (in the sense that adverse behaviors are emergent) and you can only know some stuff in restrospective. The question is always "is the team aware of the issues?" and "is management aware of the business risk technical debt poses?" and maybe "do they care?". Software sometimes is just a means to making money and if that is what the company wants, it will throw suffering at it because clean architecture, DDD etc... although nice to have are all tangential to the ultimate purpose of it. If you read these articles looking for generalisms, ground truths or recipes, you are setting yourself to failure. Context is always crucial to implementation.